5 ms·

Rereading this again I think I may have omitted one interesting point. That the 801 was, I think, one of the first computers with a split L1 cache. Will add a

Rereading this again I think I may have omitted one interesting point. That the 801 was, I think, one of the first computers with a split L1 cache. Will add a footnote in the absence of evidence to the contrary!

twoodfin 4y ago
The basic architecture diagram for the 801 is fascinating. In one sense it’s boring, because to a first approximation every modern computer is similar. On the other hand, it was the prototype for at least the subsequent 50 years of general purpose computing. From a high enough altitude, the only novelty in modern platforms is the GPU.
- klelatti 4y ago
  Absolutely. The familiarity makes it hard to appreciate the novelty. I've looked at the architecture of some of IBM's minis of the era (and some of the more ambitions microprocessors - eg iAPX432) and they just look so strange in comparison.
retrac 4y ago
I think it may have been the first microprocessor with an L1 cache of any kind. I can't find any earlier chips with on-die cache, anyway. Even the instruction prefetch queues of the 8086 and 68000 were still in the future when the IBM 801 went into manufacture. Another consequence of the RISC philosophy. After discarding all that die area for control logic, there's still some space even in a tight transistor budget to implement a cache. And since it's a clean, new architecture, you can impose restrictions on things like self-modifying code that would otherwise have made splitting the I/D caches more difficult. Cache coherency is for the compiler to worry about.
- monocasa 4y ago
  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.

twoodfin 4y ago

The basic architecture diagram for the 801 is fascinating. In one sense it’s boring, because to a first approximation every modern computer is similar. On the other hand, it was the prototype for at least the subsequent 50 years of general purpose computing. From a high enough altitude, the only novelty in modern platforms is the GPU.

klelatti 4y ago
Absolutely. The familiarity makes it hard to appreciate the novelty. I've looked at the architecture of some of IBM's minis of the era (and some of the more ambitions microprocessors - eg iAPX432) and they just look so strange in comparison.

retrac 4y ago

I think it may have been the first microprocessor with an L1 cache of any kind. I can't find any earlier chips with on-die cache, anyway. Even the instruction prefetch queues of the 8086 and 68000 were still in the future when the IBM 801 went into manufacture. Another consequence of the RISC philosophy. After discarding all that die area for control logic, there's still some space even in a tight transistor budget to implement a cache. And since it's a clean, new architecture, you can impose restrictions on things like self-modifying code that would otherwise have made splitting the I/D caches more difficult. Cache coherency is for the compiler to worry about.

monocasa 4y ago
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.