Gabriele Svelto (gabriele.svelto.delete@this.gmail.com) on January 9, 2014 2:41 am wrote:
> Nicolas Capens (nicolas.capens.delete@this.gmail.com) on January 9, 2014 12:40 am wrote:
> > Despite me calling it an L0 cache, it's not like any of the other cache "layers". It is read-only,
> > and keeping it coherent with L1 is easy since you can store the corresponding L1 cache line index
> > with each entry, and invalidate them in the same cycle the L1 cache line is invalidated.
>
> So more logic and more wires to move the data too since you're store-path now goes both
> to the L1 cache and this L0 in parallel. You probably need to hook it up to your store-queue
> too for effective load-to-store forwarding. Do you consider this simple?
>
> > Sure. Having multiple line buffers is fairly similar, and it saves
> > power: http://caps.cs.binghamton.edu/papers/ghose_islped_1999.pdf
>
> From your link:
>
> "The hardware augmentations to the basic set–associative cache are as follows. First, we need four latches
> to hold the number of the four most recently accessed sets. Second, four more comparators are needed to compare
> the set number field of the current access against the set numbers of the lines sitting in the four line buffers.
> Third, if no line buffer hit occur, the data from the set selected by the current address applied to the cache
> must be retrieved into one of the four line buffers. Consequently, on a line buffer miss, a victim must be
> selected from one of the four line buffers. The need to write back an updated line buffer’s content into
> the tag and data arrays, when the line buffer gets selected as a victim, is avoided by writing through updates
> to the line buffer into the corresponding data array on write accesses that result in a line buffer hit. Along
> with these, a multiplexing facility is needed to direct the outputs of the tag and data arrays into the victim
> line buffer. In this case, the four line buffers effectively make up a 4–entry fully–associative write–through
> cache, which is accessed in parallel with the normal cache without any prolongation in the cycle time or without
> any impact on the normal cache access pipeline."
>
> Maybe this sounds simple to you, it doesn't sound simple to me and considering nobody implemented
> anything even remotely similar also tells me it's probably not a good idea power-wise.
>

The reason line buffer and other fancy techs are ignored is that they introduce uncertainty to latency s.t. scheduler and dispatch cannot efficiently distribute opcodes and register values.
As long as Intel architects stick to traditional OoOE they won't consider these kinds of stuff.

No "L0$" in KL.