4 ms·

To be fair, the 801 wasn't a microprocessor, and it's L1 wasn't on die (because it's CPU wasn't a single die to begin with). It was implemented in MECL-10K whi

To be fair, the 801 wasn't a microprocessor, and it's L1 wasn't on die (because it's CPU wasn't a single die to begin with). It was implemented in MECL-10K which is at the sameish level of die integration as TTL, just a decent amount faster.

kragen 4y ago
And there were earlier processors that had cache; WP cites the IBM 360/85 (01969) and the Atlas 2 (01964–01966) as the first computers with CPU cache. I'm curious when the first microprocessor with cache was, since the 801 wasn't a microprocessor; the article mentions the 68040 from 01990 with a split on-die L1 cache (4K+4K), but the 68030 in 01987 had 256B+256B, and the 68020 in 01984 had 256B icache. The 68010 had a 6-byte instruction "cache" which allowed it to execute two-instruction loops without fetching instructions, but I don't think that counts. I think maybe the RISC II (01983) or the RISC I (01982) might have had a cache before the 68020. Katevenis's dissertation is at https://archive.org/details/reducedinstructi0000kate https://archive.org/details/reducedinstructi0000kate but it isn't open access and I haven't read it. It had the overlapping register windows later popularized by SPARC, though, and we often think of a register window stack as a simpler (but less effective) alternative to a dcache. According to https://en.wikipedia.org/wiki/Transistor_count https://en.wikipedia.org/wiki/Transistor_count neither the ARM 2 (01986) nor the RISC-II-descended Fujitsu SPARC MB86900 (01986) had a cache.
- fanf2 4y ago
  The first ARM with a cache was ARM3 (1989, 4kiB)
  - kragen 4y ago
    Thanks, Tony! That's what I thought. Given Sophie Wilson's concern at the time over the importance of memory bandwidth as a limiting factor in system efficiency, I wonder why they didn't at least include a 68010-like "loop mode", so you could eliminate the cost of instruction fetch in inner loops? My familiarity with ARM is not very good and so I'm not even sure if you can use LDM/STM to optimize memcpy but I'm sure it doesn't help with things like the FFT or string search.
    - fanf2 4y ago
      Yes, LDM / STM were great for memcpy-like things (eg graphics). For other loops the usual technique was to use predicated instructions to avoid pipeline flushes, and loop unrolling. You would have to ask Sophie Wilson or Steve Furber why there is no loop cache; it’s an interesting question. I guess there simply wasn’t the transistor or complexity budget for it.
- monocasa 4y ago
  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]
- rjsw 4y ago
  The Katevenis thesis describes another group at Berkeley designing an external I-cache chip to work with the RISC-II CPU, there are also a few pages analyzing how much difference a D-cache would make, doesn't look to me like RISC-II had either.
  - kragen 4y ago
    Thanks!
- AnimalMuppet 4y ago
  Off topic: I've downvoted you about five times today, and I really ought to explain why. You have good content, and it pains me to have to downvote. I'm downvoting you because of the absurd thing you do with your dates. What's absurd about it? 1. It's not the standard way of writing dates. (Communication is about finding things understood the same way between speaker and listener; non-standard usage messes with that.) 2. Because of #1, it's harder to read. It looks wrong. We have to take a half-second to think about it every single time. Multiply that by several posts a day, and also by hundreds of people reading each post, and it starts to add up to enough time to matter. This particular post is worse, because of all the CPU numbers that are five digits, and your year numbers start matching the pattern in our heads for CPU numbers. 3. It's trying to grind a Long Now axe, in a post that has nothing to do with anything related (other than having a year number in it). It's like, would you find it annoying if there was a zealous Christian on here, who had to work a reference to Jesus into every single post that mentioned philosophy or sociology? You might even find it annoying enough to start downvoting every time they did it. So, please. Stop. If you're talking only to Long Now people, use the Long Now date format. If you're trying to explain the Long Now to everyone else, explain the dates as part of that. But if you're talking to everyone else about the history of RISC, just use everyone else's date format.
  - kragen 4y ago
    > Off topic: I've downvoted you about five times today, and I really ought to explain why. You have good content You don't, so I don't see the relevance of your opinion about how I ought to write good content. Write things your way, and I'll write them my way. At its best, this site is for writing good content, not spelling flames and personal attacks on nonconformists for being weird. Nonconformists being weird is why we have computers and the internet in the first place.
    - throwawaylinux 4y ago
      Out of curiosity, why do you write years that way?
      - deleted 4y ago

kragen 4y ago

And there were earlier processors that had cache; WP cites the IBM 360/85 (01969) and the Atlas 2 (01964–01966) as the first computers with CPU cache. I'm curious when the first microprocessor with cache was, since the 801 wasn't a microprocessor; the article mentions the 68040 from 01990 with a split on-die L1 cache (4K+4K), but the 68030 in 01987 had 256B+256B, and the 68020 in 01984 had 256B icache. The 68010 had a 6-byte instruction "cache" which allowed it to execute two-instruction loops without fetching instructions, but I don't think that counts. I think maybe the RISC II (01983) or the RISC I (01982) might have had a cache before the 68020. Katevenis's dissertation is at https://archive.org/details/reducedinstructi0000kate https://archive.org/details/reducedinstructi0000kate but it isn't open access and I haven't read it. It had the overlapping register windows later popularized by SPARC, though, and we often think of a register window stack as a simpler (but less effective) alternative to a dcache. According to https://en.wikipedia.org/wiki/Transistor_count https://en.wikipedia.org/wiki/Transistor_count neither the ARM 2 (01986) nor the RISC-II-descended Fujitsu SPARC MB86900 (01986) had a cache.

fanf2 4y ago
The first ARM with a cache was ARM3 (1989, 4kiB)
- kragen 4y ago
  Thanks, Tony! That's what I thought. Given Sophie Wilson's concern at the time over the importance of memory bandwidth as a limiting factor in system efficiency, I wonder why they didn't at least include a 68010-like "loop mode", so you could eliminate the cost of instruction fetch in inner loops? My familiarity with ARM is not very good and so I'm not even sure if you can use LDM/STM to optimize memcpy but I'm sure it doesn't help with things like the FFT or string search.
  - fanf2 4y ago
    Yes, LDM / STM were great for memcpy-like things (eg graphics). For other loops the usual technique was to use predicated instructions to avoid pipeline flushes, and loop unrolling. You would have to ask Sophie Wilson or Steve Furber why there is no loop cache; it’s an interesting question. I guess there simply wasn’t the transistor or complexity budget for it.
monocasa 4y ago
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]
rjsw 4y ago
The Katevenis thesis describes another group at Berkeley designing an external I-cache chip to work with the RISC-II CPU, there are also a few pages analyzing how much difference a D-cache would make, doesn't look to me like RISC-II had either.
- kragen 4y ago
  Thanks!
AnimalMuppet 4y ago
Off topic: I've downvoted you about five times today, and I really ought to explain why. You have good content, and it pains me to have to downvote. I'm downvoting you because of the absurd thing you do with your dates. What's absurd about it? 1. It's not the standard way of writing dates. (Communication is about finding things understood the same way between speaker and listener; non-standard usage messes with that.) 2. Because of #1, it's harder to read. It looks wrong. We have to take a half-second to think about it every single time. Multiply that by several posts a day, and also by hundreds of people reading each post, and it starts to add up to enough time to matter. This particular post is worse, because of all the CPU numbers that are five digits, and your year numbers start matching the pattern in our heads for CPU numbers. 3. It's trying to grind a Long Now axe, in a post that has nothing to do with anything related (other than having a year number in it). It's like, would you find it annoying if there was a zealous Christian on here, who had to work a reference to Jesus into every single post that mentioned philosophy or sociology? You might even find it annoying enough to start downvoting every time they did it. So, please. Stop. If you're talking only to Long Now people, use the Long Now date format. If you're trying to explain the Long Now to everyone else, explain the dates as part of that. But if you're talking to everyone else about the history of RISC, just use everyone else's date format.
- kragen 4y ago
  > Off topic: I've downvoted you about five times today, and I really ought to explain why. You have good content You don't, so I don't see the relevance of your opinion about how I ought to write good content. Write things your way, and I'll write them my way. At its best, this site is for writing good content, not spelling flames and personal attacks on nonconformists for being weird. Nonconformists being weird is why we have computers and the internet in the first place.
  - throwawaylinux 4y ago
    Out of curiosity, why do you write years that way?
    - deleted 4y ago