phire

They were shipping the high-performance R4000 and R4400 with 8 stage pipelines and no branch predictors.

They could have really done with a branch predictor, each branch took three cycles (and the branch delay slot could fill only one instruction, often a useless NOP).

The Pentium only had a 5 stage pipeline and massively benefited from its branch predictor. IBM was slapping branch predictors on PowerPC designs with 4 stage integer pipelines. You simply don't need a long pipeline to justify the benefits of a branch predictor.

PowerPC 601 arrived at more or less the same time, and the Alpha 21064 was a year earlier. There were a few minicomputers and mainframes before that with branch predictors.

Arguably the 486 could have done with a branch predictor (even a single entry loop predictor would have helped), and maybe the 386 too. But microcoded CISC designs didn't benefit much from predictors because they have multiple cycles to work it out.

And RISC cpus were in their "branch delay slots are awesome" phase throughout most of the 80s. With a bit of trickery (very simple branch conditions and a 2 phase clock), your classic 5-stage MIPS design can fully hide all branches with just a single branch delay slot, so they were a little slow to adopt predictors.

I get the impression that CPU designers in the 80s and early 90s massively underestimated just how beneficial even a small predictor can be.

Which might be true? But it's a really hyper-specific claim that's far less impressive than it first sounds.

Essentially intra prediction gives you two half dimensions. The temporal aspect of inter prediction gives you a third half dimension (which we could just call time). I agree that three half dimensions is not enough.

But... intra prediction also has motion compensation, which is essentially two full spacial dimensions that are accessible as long as you are traveling along the time dimension. And apparently 2.5D is enough. [1]

I'm not sure how you can should add these dimensions together, but arguably we are talking about 3.5D, which should be way more than enough.

> This makes me think we have different ideas of what "latched storage" means.

True. The value latched at the end of the previous frame would arguably count as globally-clocked storage, not latched. It's just in regular electronics, you are using latched storage to build clocked storage, so I kind of saw clocked as a superset of latched.

Which might be true, I can't really see a reason why you couldn't construct a latch from globally-clocked storage generally (as long as you have already solved the problem of moving backwards). At least in this case it's trivial, you just move both inputs back towards the top-left of the next frame.

> I think the block that you would call a "latch in the previous frame" is functionally no different from a block elsewhere on the current frame?

The two differences are that it has been stored, and that full 2.5D movement has been unlocked.

> I don't see how it could have the same "address" but store a different value over time

You would implement this as one key frame of initial state fed into the decoder, followed by unlimited copies of a processing frame that does the calculation. The x-y position within a frame is your address, and each frame is a snapshot of time moving forwards.

I don't object to something external "feeding the same frame into the decoder" because so many early examples of things that were proved to be Turing complete required the operator to glue the input tape into a loop.

And maybe there is an existing codec or container out there that can build such a loop without anything external. And you always have the option of just building a really long file (it will even zip really well)

Though as I said, I do hesitate to label something that can't terminate out of a loop as Turing complete. But you can just make it reach a steady state and have the operator recognise when it's finished.

[1] https://cs.stanford.edu/people/eroberts/courses/soco/project...

Also quite limiting as wires could never cross.

But I was kinda jumping ahead and assuming VP8 allows you to mix and match intra and inter prediction modes within a single frame (and that inter prediction will feed into intra prediction... that might be a flawed assumption...)

Inter prediction should allow you to copy from any block on the previous frame, effetely creating unlimited length wires in any direction. This also makes the previous frame latched storage, without having to construct a latch from gates.

Not that this example doesn't have intermediate storage... But I suspect you could create or discover a mechanism that is expressive enough to implement any chain of logic gates, but is incapable of expressing storage (can't even use the gates to implement a latch)

I'm also a little dubious of granting the "Truing complete" label to something that can't conditionally terminate (at minimum)

Maybe you can trick a video codec into looping forever without new key frames (in which case it can never terminate), but most likely this would need to be implemented unrolled, so always terminates after a fixed number of iterations.

If hello world is meant to be a simplification of printing large amounts of text to a buffered standard out? Then yes, it probably should be checking errors.

If hello world is meant to be a simplification of low-volume debug logging to prove that code was reached (aka, printf debugging), then the simple alternative hello world using std.debug.print is what you want.

For such debug prints, you don't want any buffering, you don't want it mixed in with stdout (despite the name, stderr is not just for error messages), and you don't really need to check for errors. And std.debug.print does not return errors.

The Z3 is arguably more programmable than colossus and it was proven to be Turing complete in its stock configuration. Though the Z3 lacked the ability to conditionally branch, so nobody realised it at the time.

Actually, I know it's possible, that's how the automotive radars (used for adaptive cruise control) work. The real question is if someone can get enough range to pick up aircraft.

I checked, the 2nd gen iPod mini can get 18 hours of listening on a 400mAh battery, with a spinning HDD. This is getting 20+ hours listening with a 2200mAh battery and solid state storage.

Not that 20+ hours of listening is bad, I just expect a player with a battery that large to do quite a bit more.

It might be another switch. Even if it's not; VM/container networking is often implemented by bridging the host's NIC to a virtual switch, exposing the MAC addresses of all VMs/containers to the network.

On top of the lower power consumption, another advantage of the pico is that you can actually buy the raw RP2040 or RP2350 chips (for roughly $1) and make your own custom PCB.

You really don't need that much processing power to decode mp3s and FLACs.

Pry it open, replace the battery, swap the HDD for something like the iFlash.

The segment is being squeezed on at least five sides (probably more):

- Cheap low-end no-name players;

- Audiophile products like the Sony walkman stuff;

- People who are happy using their phones;

- (for the exercise "phone too heavy" use case) A smart watch, paired to bluetooth headphones;

- Second hand iPods from the 2000s, often refurbished and/or modded;

Maybe one of the low-end no-name players meets your needs... But how could you find it wading through the crap?

Most PCs in the wild were still 8088s or 286es at best.

DOS just couldn't really take advantage of a 386, so for most people, that 386 wasn't exactly useful until windows 3.0 was released in 1990. DOS extenders didn't really become mainstream until about the same time.

But most C code out there assumes malloc will always return something that is at least aligned to sizeof(void *), it's very rare to see aligned_alloc. So how is your alloc allocation going to know when it can get away with a smaller alignment?

Even if you are on a cpu that doesn't fault on unaligned memory access, any malloc implementation that doesn't align by default will have serious disadvantages in any benchmarks. IMO, There is no good reason to use an unaligned backpointer.

Malloc doesn't know the required alignment (because has no idea what the type is, everything is cast through void). So all malloc implementations have a minimum alignment guarantee. Typically 16 bytes these days on x86, as that means even 128bit SSE values will end up aligned by default.

You couldn't go below the sizeof(void ) anyway, the backpointer needs to aligned too.

The padding only happens when you use memalign or aligned_malloc to specify a much larger alignment.

I think what he is saving you can't argue the point of the scanning was to save space if you didn't destroy the original. And he concluded that "the mere conversion of a print book to a digital file to save space and enable searchability was transformative for that reason alone"

But my point is that you can't assume Anthropic would have lost if they didn't destroy the books. Alsop didn't rule on that, simply because he didn't need to. Judges hate ruling on things they don't need to.

In an alternative history where Antropic put the physical books in a warehouse after scanning, they could have argued the transformation about "minimising storage costs while increasing the easy of access" and IMO they probably would have won with that too.

But it was an important factor in the google books case.

One of the other key factors is how it impacts potential sales of the original work. Turning it into an audiobook might be transformative, but when you sell access to it people will buy your audiobook instead of the original book. So it's almost certainly not fair use.

In the google books case, google scanned the books but didn't distribute the content of the books to the user. They only distributed the transformed ability to search books to users. The sales of the books weren't impacted negatively, because the user still had to acquire a copy of the book from somewhere else if they wanted to read the whole work. In fact, google books arguable increases sales of the original work in some circumstances.

What they did was bring a case against Naspter, which ruled that ripping data off CDs AND THEN sharing it to millions of people over the internet was infringement. Not because of the ripping, but because of the sharing. The RIAA then somehow managed to twist public discourse to interpet the ruling as "ripping CDs is illegal".

They were careful, because the Sony Betamax case had already ruled that recording TV of the airwaves was legal, which is already a weaker case than ripping CDs you own. They knew such a case would likely rule against them, and they found the ambiguity to be much more useful.

And later cases like the google books case, and this Anthropic one provide even more evidence that the courts would likely rule that ripping CDs was legal if such a case was ever bought. (Though, it really depends on what you do with the digital copy)

Their MO was suing owners of internet connections which were seen sharing content on file sharing networks.

He cites three cases where a conversion from one format to another (without destruction of the previous version) was ruled to be fair use. Including scanning books with the google books case. (And referenced the Napster case, where a similar argument was rejected)

Then made the following comparison.

"Here, every purchased print copy was copied in order to save storage space and to enable searchability as a digital copy. The print original was destroyed. One replaced the other. And, there is no evidence that the new, digital copy was shown, shared, or sold outside the company. This use was even more clearly transformative than those in Texaco, Google, and Sony Betamax (where the number of copies went up by at least one), and, of course, more transformative than those uses rejected in Napster (where the number went up by “millions” of copies shared for free with others)."

So it wasn't transformative because of the destruction. The destruction only made it "even more clearly transformative" than those other cases.

Like, how can destruction be required if there were previous cases where it wasn't?

The key legal point is not that Anthropic destroyed the books, but the key fact was that Anthropic didn't distribute the scanned copies. Alsup keeps returning to this point:

"But what matters most is whether the format change exploits anything the Copyright Act reserves to the copyright owner. Anthropic already had purchased permanent library copies (print ones). It did not create new copies to share or sell outside"

"But again, the replacement copy here was kept in the central library, not distributed"

The conclusion of that section doesn't even mention the destruction at all.

arstechnica isn't exactly wrong, the quote also mentioned "and kept the digital files internally rather than distributing them". It just put way too much emphasis on the destruction, and not enough on the lack of distribution.

The other thing that arstechnica are missing:

Antropic didn't destroy the books because they thought it would strengthen their legal argument. They destroyed the because it's a lot cheaper and faster to scan books by ripping off their bindings and feeding the stacks of loose pages into a document scanner.

You have to be careful, just because the judge points a factor out as notable, doesn't mean that factor was required.

The destruction of source books makes Anthropic's fair use argument [2] especially air tight, but it would be a mistake to assume that act was required, or is what made it transformative.

In the previous google books case [1] (which this case cites), google borrowed books from libraries, scanned them, then returned them. They were not destroyed, google didn't even keep the physical copy.

Yet Google Books was ruled fair use, because it was transformative.

[1] https://en.wikipedia.org/wiki/Authors_Guild,_Inc._v._Google,....

[2] Note... This part of the ruling is still not about LLMs. This was about Anthropic's right to scan books and then keep a digital library of them.

At least not as far as the courts are concerned. Alsup ruled [0] that feeding a book into an LLM is transformative and counts as fair use. Especially when they purchased a physical copy of the book, scanned it, and destroyed the original.

But if I'm reading the ruling correctly, Anthropic might have been fine even with feeding pirated books into their LLM (as long as they planned to eventually deleted them afterwards)

Where Anthropic ran into problems is that they put all their pirated books into a big central library (file on a server), and planned to keep those copies forever. Including copies they never actually fed into the LLM (a point that seriously worked against them).

Alsup ruled this central library of pirated books was copyright infringement. And it's this "pirated central library" that Anthropic are now paying a a 1.5B settlement for, nothing else.

The fact that the pirated books were also used to train LLMs is legally irrelevant. Though... I suspect a non AI company could have negotiated a significantly smaller settlement.

[0] https://copyrightalliance.org/wp-content/uploads/2025/06/Bar...

Already has variable substitution and math, it seems to falls short of Turing completeness only because I don't see any form of recursion. But recursion is something it could accidentally gain if someone decided to add templating to the language.

Besides, looks the config files can call out to external executables, which absolutely are Turing complete. And moving to lua might actually simplify configs by allowing more things to be done inside the config system, rather than calling out.

Ah, cracking. Another thing the RISC-V ISA will try to avoid at all costs.

> I don't think they would've added 3r1w if it wasn't for the complex load/stores.

Agreed. The complex load/store addressing is one of the fundamental parts of the original ARM design, and IMO the only one that really survived into AArch64 unscathed.

It actually needs to be 3r2w so that it can writeback both the updated base register and memory value for indexed loads.

And if you already need 3r2w (or to emulate it via cracking), might as well add other instructions to take advantage of it.

> I think it's a fine way to design an ISA

Really depends on what the design criteria are. If the goal is to create a "better MIPS" or "Easy to implement ISA, great for education" or "Optimised for low-transistor classic-RISC pipelines", then avoiding flags is a great idea.

And a good idea to avoid cracking, it just adds complexity and pushes you away from that "RISC purity". TBH, I'm a little surprised they got rid of branch delay slots, but I guess they really confuse people writing assembly (or compilers).

In many ways RISC-V is a great ISA, the extendability and openness is unparalleled and it does actually deliver on scaling all the way from ultra-low transistor designs, all the way up to high-performance out-of-order cores.

But if the design criteria is "An Open ISA optimised for the modern era", then I think RISC-V falls short. And the choice to avoid flags is one of the many minor issues that add up to making RISC-V sub-optimal for higher-end μarches.

But it does require three input registers. One for a control value, plus the two options. And RISC-V has a thing about not requiring three input registers.... Yeah, I'm not a fan of RISC-V.

One of the other major advantages of flags is it allowed for a cheap third input to certain instructions (like cmov, adc, ccmp), without requiring a full 3R1W register file.

The fact that it's possible to design a viable ISA without flags is really neat, it was absolutely worth trying. But MIPS already proved it was possible, and showed all the downsides, it did not need to be tried a second time with RISC-V.

So it must be something about limiting the complexity of the flags register file and/or its bypass network.

> But I hadn't considered the ISA design option of only carry flag, no seperate cmp and branch, before.

Well, RISC-V does have a decent point: Most of the time you simply don't need flags. The only area this approach falls apart is detecting overflow or add-with-carry.

So, why not just cover that flaw by adding a carry/overflow flag.

The counter-argument is that as soon has you "ruin the purity of the design" by adding one flag, you might as well add the complete set of all four. Then you can simply branch instruction encodings, and use the extra bits for something else (like seperate set-flags versions of all the ALU instructions)