3 ms·

Isn't that, in itself, a condemnation of CISC? The instruction set is so complex that the CPU has to translate to microcode at runtime. If the compiler could e

Isn't that, in itself, a condemnation of CISC? The instruction set is so complex that the CPU has to translate to microcode at runtime. If the compiler could emit that microcode directly, it would be easier to optimize and the CPU wouldn't have the task of decoding and translating the CIS.

akelly 4y ago
Having a translation layer means you can have a stable API that the compilers can target (the ISA) and then be able to make breaking changes to the microcode API every processor generation to improve performance.
lmm 4y ago
The counterargument is that RISC architectures end up needing to use compressed instruction formats (e.g. ARM Thumb) because their clean orthogonal instruction encoding is so inefficient (e.g. it wastes a lot of instruction cache). If you already need the compiler to output some compressed encoding that your processor is going to uncompress at runtime, well, why not keep that uncompressed format as an implementation detail that you can change in future models of your processor?
- _chris_ 4y ago
  > their clean orthogonal instruction encoding is so inefficient (e.g. it wastes a lot of instruction cache) Perhaps, although ARMv8 is fixed 4 bytes and x86-64 averages more than 4 bytes an instruction despite each x86 instruction mapping to more than 1.0 uops on average. Oops.
  - rcxdude 4y ago
    That doesn't really say anything about efficiency of coding, because you're missing the important component of how much work each instruction represents. If ARMv8 turns 'load, multiply, store' into 3 instructions of 4 bytes and x86 represents that as 1 5-byte instruction decoding to 1 uop, x86 is going to be winning on most counts (2x in terms of code density). Of course the reality is probably going to be closer than this, but your statements contain none of the information to actually make any determination one way or the other.
erik_seaberg 4y ago
Decoding instructions is ugly but a solved problem. As for scheduling instructions optimally, Itanium tried this, but they never achieved a “sufficiently smart compiler” to make full use of the microarchitectural pipelines and registers (and cache?). Even if they had, that code might make poor use of future CPUs, because more pipelines will be available for more instructions or retire some of them faster than expected.
- ncmncm 4y ago
  Scheduling instructions optimally needs runtime information not available to compilers, even if they were correctly told the architectural generation. But, yes, compilers rarely are told the right architectural generation to target.
robocat 4y ago
Watch the interviews with Jim Keller. reduced instruction sets don’t have any advantage, because if I recall what he said correctly, decoding and translating are a very small part of the transistor and latency budget. Missed branch prediction, cache and memory access are what matters for a modern CPU. Fetching from main memory has a cost, just like fetching off spinning rust used to, so hoops are jumped through to avoid memory stalls.
gpderetta 4y ago
High performance RISCs also have decoders and have the equivalent of uops internally as well. Their decoders are simpler than a CISC like x86, which has a very baroque encoding. Still the claim that x86 implementations are RISC internally is not really true.

akelly 4y ago

Having a translation layer means you can have a stable API that the compilers can target (the ISA) and then be able to make breaking changes to the microcode API every processor generation to improve performance.

lmm 4y ago

The counterargument is that RISC architectures end up needing to use compressed instruction formats (e.g. ARM Thumb) because their clean orthogonal instruction encoding is so inefficient (e.g. it wastes a lot of instruction cache). If you already need the compiler to output some compressed encoding that your processor is going to uncompress at runtime, well, why not keep that uncompressed format as an implementation detail that you can change in future models of your processor?

_chris_ 4y ago
> their clean orthogonal instruction encoding is so inefficient (e.g. it wastes a lot of instruction cache) Perhaps, although ARMv8 is fixed 4 bytes and x86-64 averages more than 4 bytes an instruction despite each x86 instruction mapping to more than 1.0 uops on average. Oops.
- rcxdude 4y ago
  That doesn't really say anything about efficiency of coding, because you're missing the important component of how much work each instruction represents. If ARMv8 turns 'load, multiply, store' into 3 instructions of 4 bytes and x86 represents that as 1 5-byte instruction decoding to 1 uop, x86 is going to be winning on most counts (2x in terms of code density). Of course the reality is probably going to be closer than this, but your statements contain none of the information to actually make any determination one way or the other.

erik_seaberg 4y ago

Decoding instructions is ugly but a solved problem. As for scheduling instructions optimally, Itanium tried this, but they never achieved a “sufficiently smart compiler” to make full use of the microarchitectural pipelines and registers (and cache?). Even if they had, that code might make poor use of future CPUs, because more pipelines will be available for more instructions or retire some of them faster than expected.

ncmncm 4y ago
Scheduling instructions optimally needs runtime information not available to compilers, even if they were correctly told the architectural generation. But, yes, compilers rarely are told the right architectural generation to target.

robocat 4y ago

Watch the interviews with Jim Keller. reduced instruction sets don’t have any advantage, because if I recall what he said correctly, decoding and translating are a very small part of the transistor and latency budget. Missed branch prediction, cache and memory access are what matters for a modern CPU. Fetching from main memory has a cost, just like fetching off spinning rust used to, so hoops are jumped through to avoid memory stalls.

gpderetta 4y ago

High performance RISCs also have decoders and have the equivalent of uops internally as well. Their decoders are simpler than a CISC like x86, which has a very baroque encoding. Still the claim that x86 implementations are RISC internally is not really true.