[kragen]

While that was very important, wasn't the ARM2 with no cache significantly faster than contemporary CISC processors like the 80386 with no cache?

I know Dhrystone isn't real but https://www.realworldtech.com/arms-race/2/ says an 8 MHz Archimedes got 4901 Dhrystones per second to the 16-MHz 386's 3626 Dhrystones per second. https://en.wikipedia.org/wiki/Instructions_per_second gives the 8-MHz ARM2 4 [Dhrystone] MIPS at 8 MHz and the 16-MHz "i386DX" 2.15 MIPS at 16 MHz. In fact, the cacheless ARM2 even beat the CISC 68020, which did have a tiny cache!

Also, I think squished RISC instruction encodings like Thumb, MIPS16, and RVC seem pretty competitive with popular CISCs on code density; RVC even seems to best them. So even if your data access is competing with instruction fetch for memory bandwidth because you don't have an icache, you'd probably still get more instructions per memory cycle out of RVC than out of i386 or AMD64.

[klelatti]

Yes I think cache was an important motivator for some early designs (eg the IBM 801 - shameless plug below! [1]) as the central idea was that fast instruction cache would replace fast microcode store thus removing any code size penalty.

In fact I don't think code size was that much bigger for these designs so cache was probably less important than they initially thought.

The Arm team recognised that memory bandwidth was key for a cache less design and so designed to maximise this and make the most of it - hence the outperformance.

[1] https://thechipletter.substack.com/p/the-first-risc-john-coc...