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.
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 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 neither the ARM 2 (01986) nor the RISC-II-descended Fujitsu SPARC MB86900 (01986) had a cache.
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.
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.
> 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...
[1]- https://people.eecs.berkeley.edu/~pattrsn/Arch/RISC2.jpg
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?
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.
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.
(there is a —very— small community which schedules working hours around ~25 hour "sols", but I doubt they reckon by 668 sol years; does anyone know?)
300 years ago, the advantages of 1722 over MDCCXXII were blindingly obvious. It wouldn't be what I was then used to, but it had clear advantages. Whereas today, the advantages of writing 02022 are... um... that kragen likes to do it that way.
Moving the N-digit rollover from 8000 years from now to 98000 years from now, which... isn't.
Basically you might have more success when your reasoning for stopping doesn't also coincide with why someone might be doing it in the first place.
I may be alone in being annoyed enough to write a rant about it, but I suspect I'm not alone in being annoyed by it, especially when he does it over and over. His stunt may be useful in drawing attention, but I suspect it's counterproductive at drawing agreement.