Hacker News Reader

Comment by retrac | Hacker News Reader

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.

View on HN

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.

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 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.

The first ARM with a cache was ARM3 (1989, 4kiB)

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.

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.

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...

[1]- https://people.eecs.berkeley.edu/~pattrsn/Arch/RISC2.jpg

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?

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.

Thanks!

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.

> 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.

Out of curiosity, why do you write years that way?

When I see a number with a leading zero, I think “octal”. Perhaps octal years are A Thing?

Compared to some other possibilities: MCMLXX or 5730 (let alone An CLXXVIII or 62 AF) I find 01970 (or even 000001970) amazingly harmless.

(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 people like AnimalMuppet would have attacked you for writing the date as 1722 instead of MDCCXXII, for precisely the same reasons, and been precisely as correct. Fortunately not everyone is like that.

Yeah, thanks for telling me what I would have done 300 years ago. Nice time machine you've got, to be able to tell that.

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.

> Whereas today, the advantages of writing 02022 are...

Moving the N-digit rollover from 8000 years from now to 98000 years from now, which... isn't.

Aren't your complaints the explicit goal of that date format? It's supposed to trip people up for a second to get them think about years with a different exponent on the floating-poibt/scientific-notation representation our brains fall into using pretty much all of the time. And that in this context there is no true 'appropriate' time besides maybe an emergency situation where understanding on a hard real time latency is paramount.

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.

His clever way of tripping me up annoys me. Do you think that makes me more likely to adopt his viewpoint? Or less?

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.

Reply on news.ycombinator.com