4 ms·

Huh, that's a great question. I'm certainly struggling to find something earlier than the 68020 as well. > We decided that RISC I should not be burdened with t

Huh, that's a great question. I'm certainly struggling to find something earlier than the 68020 as well. > We decided that RISC I should not be burdened with the design of a full-blown on-chip cache, but an instruction cache would definitely be a good idea for the next-generation RISC.[0] So it seems RISC-I didn't. Additionally a die shot[1], and understanding of the architecture of RISC-II (doubling down on the big window register file as a potential substitute for on die D cache) appears to imply that it doesn't have any on die cache, I or D. I certainly don't see any arrays of SRAM other than the register file. [0] - https://people.eecs.berkeley.edu/~kubitron/courses/cs252-F00/handouts/papers/p216-patterson.pdf https://people.eecs.berkeley.edu/~kubitron/courses/cs252-F00... [1]- https://people.eecs.berkeley.edu/~pattrsn/Arch/RISC2.jpg https://people.eecs.berkeley.edu/~pattrsn/Arch/RISC2.jpg

kragen 4y ago
Thank you! I wasn't confident in understanding the die shots. With 40 years of hindsight I think we can probably conclude that caches are a better use of excess on-die transistors than register windows are? Even though register windows theoretically reduce the cost of subroutine calls and thus of good factoring. I feel like even a fairly small instruction cache, or explicitly-used instruction scratch memory, could have produced big payoffs in reducing instruction fetch cost, especially for RISC designs without hardware indirection? Like, if your compiler emitted explicit code at the beginning of every short leaf function to load it into instruction scratch memory, then run the scratch memory, instead of running it from RAM? At least if it contained a backward branch?
- deleted 4y ago
  [deleted]