3 ms·

I'm a dummy. Do I have this right? > CISC-to-RISC translation on the front end I would naively assume that this would be an advantage, since you could easily

by nomel 4y ago

I'm a dummy. Do I have this right? > CISC-to-RISC translation on the front end I would naively assume that this would be an advantage, since you could easily change the hardware used for any CISC instruction, finding better ways to make it faster. The "work unit" is more abstract, so you could throw the whole problem at dedicated silicon. Or, you could remove dedicated silicon, and just have the CIST spit out a list of RISC instructions. It seems that, for RISC, you could never throw a more abstract "work unit" at dedicated silicon, without buffering instructions, to see if the intent matches the accelerators. Chip specific compilers would almost be required, to handle the abstraction.

mnw21cam 4y ago
It was an advantage. Now it's a liability, because it is hard to scale the CISC-to-RISC translation up to decode many instructions per clock cycle. The translation unit has become the bottleneck.
- nomel 4y ago
  Why? Wouldn’t it be adding a list of instructions to the queue, for the RISC side? Why would that RISC side have to be slower? I would assume it would be mostly independent. Or is that queue pollution the problem, rather than the execution of it?
  - mnw21cam 4y ago
    The problem is that CISC instructions are variable-length, so it's easy to work out how to decode the first instruction, but the second instruction depends on the length of the first instruction, and if you try to decode four instructions at once in a single clock cycle then it all gets a bit too much, which reduces your maximum clock speed. In comparison, a RISC instruction decoder knows that each instruction is the same length, so each instruction can be decoded without depending on the ones before it. This simplifies the decoder so much that it makes it possible to decode four instructions per clock cycle without investing in too much silicon to do it, and while keeping a high clock speed.

by nomel 4y ago

mnw21cam 4y ago

It was an advantage. Now it's a liability, because it is hard to scale the CISC-to-RISC translation up to decode many instructions per clock cycle. The translation unit has become the bottleneck.

nomel 4y ago
Why? Wouldn’t it be adding a list of instructions to the queue, for the RISC side? Why would that RISC side have to be slower? I would assume it would be mostly independent. Or is that queue pollution the problem, rather than the execution of it?
- mnw21cam 4y ago
  The problem is that CISC instructions are variable-length, so it's easy to work out how to decode the first instruction, but the second instruction depends on the length of the first instruction, and if you try to decode four instructions at once in a single clock cycle then it all gets a bit too much, which reduces your maximum clock speed. In comparison, a RISC instruction decoder knows that each instruction is the same length, so each instruction can be decoded without depending on the ones before it. This simplifies the decoder so much that it makes it possible to decode four instructions per clock cycle without investing in too much silicon to do it, and while keeping a high clock speed.