3 ms·

The problem is that you don't know the instruction length until you've decoded it so where is the size cache getting the size?

dragontamer 5y ago
> The problem is that you don't know the instruction length until you've decoded it so where is the size cache getting the size? You are aware that x86 _CURRENTLY_ (ie: without size-cache) decodes 4-instructions per clock tick, right? That's in parallel, as currently implemented. Intel just seems to think the size-cache is a potential solution for going faster. I've given it some thought and it seems like it could very well be worth the 4-bits (or so) per byte it'd cost. ---------- A parallel size-calculator would also be O(n) work and O(log(n)) depth, by using a parallel regex/finite automata on calculating the sizes for arbitrary lengths upwards.
- Veliladon 5y ago
  That's only second stage decoding. In the fetch/pre-decode stage there is a specific piece of hardware that partially decodes 16 byte chunks of instruction streams before inserting instructions into the instruction queue for the decode from macro-op to uop. It can only handle 6 instructions per clock and 16 bytes per clock. If you have 7 instructions in a 16 byte block it takes two cycles to process that block. If you have only 2 instructions in that 16 byte block you only get those two instructions. It also only looks for instruction length and branching to feed the branch predictor, spitting the same instructions back out albeit fused and tagged with index numbers for insertion into the instruction queue ready for the second stage decoders. This is the length that Intel has to go to in order to keep the EUs fed. Apple/ARM? Every 4 bytes there's an instruction.
  - dragontamer 5y ago
    I'm talking 1st stage decoding actually. I'm ignoring the uOp cache. The 2nd stage uop can go 6-per or 7-per clock tick. But 1st stage (which executes in practice when the uop cache is thrashing) would still go 4-instructions per clock tick just fine. > This is the length that Intel has to go to in order to keep the EUs fed. Yeah. And the task described is O(n) total work and O(log(n)) depth. So... not a big difference? I'd have my doubts that the instruction-length portion of the decoder was taking up a significant amount of power.

dragontamer 5y ago

> The problem is that you don't know the instruction length until you've decoded it so where is the size cache getting the size? You are aware that x86 _CURRENTLY_ (ie: without size-cache) decodes 4-instructions per clock tick, right? That's in parallel, as currently implemented. Intel just seems to think the size-cache is a potential solution for going faster. I've given it some thought and it seems like it could very well be worth the 4-bits (or so) per byte it'd cost. ---------- A parallel size-calculator would also be O(n) work and O(log(n)) depth, by using a parallel regex/finite automata on calculating the sizes for arbitrary lengths upwards.

Veliladon 5y ago
That's only second stage decoding. In the fetch/pre-decode stage there is a specific piece of hardware that partially decodes 16 byte chunks of instruction streams before inserting instructions into the instruction queue for the decode from macro-op to uop. It can only handle 6 instructions per clock and 16 bytes per clock. If you have 7 instructions in a 16 byte block it takes two cycles to process that block. If you have only 2 instructions in that 16 byte block you only get those two instructions. It also only looks for instruction length and branching to feed the branch predictor, spitting the same instructions back out albeit fused and tagged with index numbers for insertion into the instruction queue ready for the second stage decoders. This is the length that Intel has to go to in order to keep the EUs fed. Apple/ARM? Every 4 bytes there's an instruction.
- dragontamer 5y ago
  I'm talking 1st stage decoding actually. I'm ignoring the uOp cache. The 2nd stage uop can go 6-per or 7-per clock tick. But 1st stage (which executes in practice when the uop cache is thrashing) would still go 4-instructions per clock tick just fine. > This is the length that Intel has to go to in order to keep the EUs fed. Yeah. And the task described is O(n) total work and O(log(n)) depth. So... not a big difference? I'd have my doubts that the instruction-length portion of the decoder was taking up a significant amount of power.