Timeline for Why did Intel abandon unified CPU cache?
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 23, 2022 at 12:26 | comment | added | Peter Cordes | given the development practices at the time on x86 - Even if self-modifying code wasn't common, it's essential for a new x86 CPU to be able to run existing binaries. Including very old binaries. Even one or two commercially-relevant uses of self-modifying code would be enough to require coherent I-cache, so this shouldn't be taken as implying that SMC was common. Of course, JIT is a big thing these days, and looks similar to the CPU (execution of recently-written bytes); other ISAs do need to run some barrier and/or cache-flush instructions after store instructions, before a jump. | |
| Jun 10, 2019 at 15:45 | vote | accept | Brian H | ||
| Jun 9, 2019 at 8:58 | comment | added | Peter Cordes | @supercat: yes, exactly, that was my point. A unified L1 solves the coherence problem trivially, vs. needing something like MESI or probing both tags on stores to make L1i + L1d coherent with each other. (And probing both tags would negate some of the physical chip-layout + fewer read-port advantages of split caches by requiring that the store-data execution unit be connected to L1i cache as well.) | |
| Jun 9, 2019 at 6:49 | comment | added | supercat | @PeterCordes: ON the 8086 and probably 80286 and 80386 as well, there was no effort to invalidate pre-fetched instructions that were overwritten by a store, but there was also no effort to avoid having to re-fetch instructions from scratch after a jump. On the 80486, the whole point of the cache was to avoid having to re-fetch instructions in a loop, which meant there had to be some other means of ensuring that stale instructions wouldn't get written. | |
| Jun 8, 2019 at 20:20 | comment | added | Peter Cordes | On early CPUs the pipeline might not have been coherent with stores, so a jump of any kind was necessary for SMC to be guaranteed to be picked up. But x86 has continued to maintain coherent instruction caches and pipeline, even snooping stores for all instructions in flight for out-of-order execution. Observing stale instruction fetching on x86 with self-modifying code - stale instruction fetch is impossible because sometimes it's easier to go beyond the paper spec than to be exactly as strong (requiring a jmp). | |
| Jun 8, 2019 at 20:15 | comment | added | Peter Cordes |
@BrianH: Most classic-RISC ISAs (like MIPS that were designed from the ground up for pipelined implementations) do not have coherent instruction caches: you have to run a sync/flush instruction before you can safely jump to an address where the CPU recently used store instructions to store new machine code. x86 on paper required a serializing instruction (like cpuid except it didn't exist until late 486, so there weren't any good user-space choices). In practice CPU vendors wanted to not break existing self-modifying code (primitive JITs or whatever). Coherent L1i + pipeline is harder!
|
|
| Jun 8, 2019 at 20:09 | comment | added | Peter Cordes | @BrianH: Split L1 caches are certainly more natural for a pipelined CPU that's normally fetching instructions in parallel with data loads / stores. Two separate caches are cheaper to build than 1 larger multi-ported cache. And yes, tightly integrating the L1d with load/store ports and L1dTLB, and L1i with L1iTLB and instruction fetch, is another well-known advantage of split caches, as @HadiBrais discussed in an SO answer. Many wires (silicon or metal) over long distances are something to avoid. (P5 has 64-bit wide cache access paths). | |
| Jun 7, 2019 at 12:11 | history | edited | Stephen Kitt | CC BY-SA 4.0 |
Mention the die layout aspect.
|
| Jun 7, 2019 at 11:36 | comment | added | Stephen Kitt | It looks like the Pentium layout benefits from separate caches. | |
| Jun 7, 2019 at 11:31 | comment | added | Stephen Kitt | Yes, I came across that too; if (and this is a big if) the on-die layout of the 486 is anything like this block diagram, it wouldn’t be an issue there, but it could easily have been a problem on the Pentium (and also on the 68040). I imagine there are annotated die shots of 486s and Pentiums somewhere... | |
| Jun 7, 2019 at 11:18 | comment | added | Brian H | Solid answer. I saw something in my own research suggesting that the physical placement/location on-die of the cache was critical for minimizing cache latency, and this led some designers to Harvard arch. So wondering if that also played a role with Intel switch for P5. | |
| Jun 7, 2019 at 8:59 | history | answered | Stephen Kitt | CC BY-SA 4.0 |
