4 ms·
While decoding a given x86 instruction is serial, since about 2000 metadata has been added to the L1 instruction cache indicating which bytes start an instructi
by brucehoult 5y ago
While decoding a given x86 instruction is serial, since about 2000 metadata has been added to the L1 instruction cache indicating which bytes start an instruction. So you can start decoding multiple instructions in parallel.
Doing the same might be useful on a very wide RISC-V decoder. Not needed for 3 or 4 wide though. This is not very expensive, needing only 1 bit per 16 bits of instruction cache data (6.25% overhead), as RISC-V instructions can only start on 2 byte boundaries. This is quite small compared to the 25% to 30% code size you typically save from using both 2 and 4 byte instructions (30% to 50% more instructions in a cache of fixed size).
x86 also uses cache of the micro-ops generated from each instruction, to avoid decoding recently-used instructions at all. That's completely unnecessary with simple instruction encodings such as RISC-V.
- hajile 5y agoI assume you’re talking about HAT (head on tails). The only way to mark in cache is to analyze the incoming streams which still uses significant power and can itself be bottlenecked. As I recall, there’s also occasional waste space on x85 because there’s so many length options. With RISC-V, chunks parse faster because you can skip (eg) 512 bytes and I believe only the last two bytes need to be inspected to ensure it’s sliced and potentially padded correctly. At that point, I don’t know that any other scheme is needed. All the fast ARMv8 implementations use uop cache and fast RISC-V implementations will do the same as they gain an even bigger advantage.