Hacker News Reader

Comment by bombcar | Hacker News Reader

And x86 is arguably a CISC layer on top of a RISC processor. I don’t think the divisions of the 90s any longer directly apply.

View on HN

^this, there are more layers now, and it's all fairly RISC like at the bottom or so I'm told.

This is a bit of a myth: microcode is used a lot in x86, but a lot of it is for emulating obselete instructions. The vast majority of instructions on x86 are still directly implemented in the hardware (including such decidedly non-RISC instructions as 'take this register, multiply it by 4, add it to this other register, then load that address from memory and do a floating-point multiplication of it with this 3rd register and store the result there', all without any microcode). If anything the RISC side of the coin (ARM) has become much more CISC like over time.

Also not entirely true. All x86 instructions are translated into an internal microcode/uop format; only the "complex" ones use the "microcode ROM".

The execution units don't know what `01 C0` (add eax, eax) means; only the decoder does. The decoder turns those bytes into something like `eax := ADD_DSZ32(eax, eax)` that the execution unit understands.

For example, `01 01 00 00` (add [ecx], ebx) is probably translated by the PLAs into 3 uops similar to these:

    tmp0 := LOAD_DSZ32(ecx)
    tmp0 := ADD_DSZ32(tmp0, eax)
            STORE_DSZ32(ecx, tmp0)

But any operation requiring four or more uops (such as "complex addressing") would go to either the "long" decoders or the microcode ROM

Ok now I'm confused. Is it possible you are both correct but your understanding are from different points in time where microcode based ops have been used more over time? i.e would the GPs comment be correct for a specific, older generation of intel x86, and yours perhaps be more applicable to newer generations?

My understanding is: every x86 processor from Intel and AMD has been microcoded to an extent. The 8086 through the 808486 used a "horizontal microcode" PLA (like all microprocessors of the era), but when Intel introduced the first superscalar x86 processor, the P5, they switched to "vertical microcode". IIRC, that vertical microcode has always been based around "simple" decoder PLAs and a "complex" decoder ROM.

Horizontal microcode is the execution unit control lines being toggled directly by the PLA. Vertical microcode (of the P5 and up) is more in line with what people understand "microcode" to be, but it's still internal uops, never "raw" x86 instructions. The encoding of the actual uop can usually be roughly correlated with the external ISA encoding, but that's just to ease work on the decoder.

Realistically, with CISC, you'll always have a microcode sequencer of some sort. More broadly, short of a TTA, there's going to be a PLA somewhere.

[0]: https://en.wikipedia.org/wiki/Transport_triggered_architectu...

Thanks! Strangely I wouldn't have guessed the 8086 had anything resembling microcode, even though when I think about it there are obvious examples of earlier microcoded CPUs - My understanding is definitely too vague, I wasn't even aware of the distinction between horizontal and vertical, thanks for highlighting the depth of this to me.

Sure thing! The world of microarchitecture is really interesting IMO.

If you're referring to uops, that's closer to VLIW than RISC.

AFAIK the whole RISC vs CISC thing has always been more about the software-visible instruction set than the implementation.

It was definitely about the implementation in the beginning.

why would uops similar to VLIW? because they are very large and potentially encode control bits for multiple execution units? I never thought of them like that, but it could be a reasonable way to view them.

Micro-ops aren't RISC instructions, too complex. For instance, vfmadd132ps instruction loads 32 bytes from memory, multiplies by 8 FP32 numbers, adds to another 8 numbers - yet on most processors that instruction decodes into a single micro-op.

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.

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?

> 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.

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.

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.

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.

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.

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.

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.

Reply on news.ycombinator.com