4 ms·

It is a Reduced Instruction Set computer. It's a greatly simplified design. The x86_64 ISA is absolutely insane. The only way to implement it in hardware effic

It is a Reduced Instruction Set computer. It's a greatly simplified design. The x86_64 ISA is absolutely insane. The only way to implement it in hardware efficiently is to "compile" the super complicated instructions into micro-ops which can actually be decoded and executed on the CPU. Said another way, Intel has to implement a compiler in hardware which compiles the machine code before it gets executed. The extra complexity means more power and less performance. You can read more about how microcode and micro ops work here: https://en.m.wikipedia.org/wiki/Intel_Microcode https://en.m.wikipedia.org/wiki/Intel_Microcode

umanwizard 6y ago
I don't think that's the entire reason. Most of the common x86 instructions occurring in a normal program can be decoded to a few uops in a straightforward way, and since Sandy Bridge the decoded uops are cached anyway. So this would only be a significant bottleneck for hot loops that are large enough that they don't fit in the uop cache. It's definitely a real issue but it seems wrong to pin all or even most of Intel's stagnation on that.
cesarb 6y ago
> The x86_64 ISA is absolutely insane. The only way to implement it in hardware efficiently is to "compile" the super complicated instructions into micro-ops which can actually be decoded and executed on the CPU. > Said another way, Intel has to implement a compiler in hardware which compiles the machine code before it gets executed. The extra complexity means more power and less performance. This is a sadly prevalent misconception. There is no "compiler in hardware". There are two kinds of instructions; the simpler ones (which are the most common) are expanded directly into a fixed sequence of micro-ops, while the more complicated ones act like a subroutine call to the microcode. The closest software analogue would be a macro assembler, not a compiler. AFAIK, the extra complexity for efficiently decoding x86 instructions comes mostly from their variable length without an explicit length indication, and from the variable number of prefixes which can change the interpretation of the following byte, which makes decoding an instruction a serial task. IIRC, both Intel and AMD have a couple of tricks to reduce the impact this has on both power and performance: caching the already decoded micro-ops, and storing the instruction boundaries in the L1 instruction cache.
jeffbee 6y ago
So, that's the freshman-year CS view of the topic, but back here in reality land the "complicated" x86 instruction format has pretty much destroyed all others and none of the supposed advantages of RISC actually exist. Remember that the whole point of RISC is that the CPUs would supposedly run faster. That hasn't happened. There are no RISC CPUs running faster than state-of-the-art x86 CPUs. POWER8 comes closest, but does not exceed. The whole RISC philosophy was a huge mistake. Yes, x86 instructions do not map well to transistors, and they have to be unpacked into uops to be executed. This is a form of compression. Having a compressed program image turns out to be a massive advantage. RISC proponents thought that x86 was so complicated they could beat Intel with their simple instruction decoders. That almost, but not really, made sense in 1990 but since then has made increasingly less sense, until today where the amount of sense this makes has hit zero. The x86 instruction decoder is a very small part of the floor plan of a modern CPU and every time they rev the microarchitecture it gets smaller. The number of transistors needed to decode the VEX prefix is like a speck of sand on the beach of a 512x512-bit multiplier.
- acidbaseextract 6y ago
  > The whole RISC philosophy was a huge mistake. Yes, x86 instructions do not map well to transistors, and they have to be unpacked into uops to be executed. The RISC philosophy wasn't a mistake. Our architectures have just become more sophisticated so that we don't have to make a binary choice. The hybrid is good. The internal uops get the pipelining advantages of RISC, while we get the encoding compression of a CISC instruction set.
gandalfgeek 6y ago
If you look at the latest ARM instruction sets they are not really "RISC". Sure, they're much saner than than the crazy legacy instructions that x86 carries, but still nowhere near a "real RISC" ISA as espoused by Hennessy and Patterson, the hallmarks of which are simple, orthogonal, atomic instructions, and a small number of them. Currently that is most closely embodied by RISC-V. If you look at how you can get computing gains going forward after the end of Moore's law, of course the glib answer is "parallelize across more cores!" but the more interesting path is to notice that behemoth single cores like x86 spend a ton of silicon area trying to optimize straight-line execution with things like speculative execution. If you saved all that silicon area, making each single core slower but smaller, but packed more cores on the die as a result, you would most likely come out faster. [1] [1]: https://science.sciencemag.org/content/368/6495/eaam9744/tab-pdf https://science.sciencemag.org/content/368/6495/eaam9744/tab...

umanwizard 6y ago

I don't think that's the entire reason. Most of the common x86 instructions occurring in a normal program can be decoded to a few uops in a straightforward way, and since Sandy Bridge the decoded uops are cached anyway. So this would only be a significant bottleneck for hot loops that are large enough that they don't fit in the uop cache. It's definitely a real issue but it seems wrong to pin all or even most of Intel's stagnation on that.

cesarb 6y ago

> The x86_64 ISA is absolutely insane. The only way to implement it in hardware efficiently is to "compile" the super complicated instructions into micro-ops which can actually be decoded and executed on the CPU. > Said another way, Intel has to implement a compiler in hardware which compiles the machine code before it gets executed. The extra complexity means more power and less performance. This is a sadly prevalent misconception. There is no "compiler in hardware". There are two kinds of instructions; the simpler ones (which are the most common) are expanded directly into a fixed sequence of micro-ops, while the more complicated ones act like a subroutine call to the microcode. The closest software analogue would be a macro assembler, not a compiler. AFAIK, the extra complexity for efficiently decoding x86 instructions comes mostly from their variable length without an explicit length indication, and from the variable number of prefixes which can change the interpretation of the following byte, which makes decoding an instruction a serial task. IIRC, both Intel and AMD have a couple of tricks to reduce the impact this has on both power and performance: caching the already decoded micro-ops, and storing the instruction boundaries in the L1 instruction cache.

jeffbee 6y ago

So, that's the freshman-year CS view of the topic, but back here in reality land the "complicated" x86 instruction format has pretty much destroyed all others and none of the supposed advantages of RISC actually exist. Remember that the whole point of RISC is that the CPUs would supposedly run faster. That hasn't happened. There are no RISC CPUs running faster than state-of-the-art x86 CPUs. POWER8 comes closest, but does not exceed. The whole RISC philosophy was a huge mistake. Yes, x86 instructions do not map well to transistors, and they have to be unpacked into uops to be executed. This is a form of compression. Having a compressed program image turns out to be a massive advantage. RISC proponents thought that x86 was so complicated they could beat Intel with their simple instruction decoders. That almost, but not really, made sense in 1990 but since then has made increasingly less sense, until today where the amount of sense this makes has hit zero. The x86 instruction decoder is a very small part of the floor plan of a modern CPU and every time they rev the microarchitecture it gets smaller. The number of transistors needed to decode the VEX prefix is like a speck of sand on the beach of a 512x512-bit multiplier.

acidbaseextract 6y ago
> The whole RISC philosophy was a huge mistake. Yes, x86 instructions do not map well to transistors, and they have to be unpacked into uops to be executed. The RISC philosophy wasn't a mistake. Our architectures have just become more sophisticated so that we don't have to make a binary choice. The hybrid is good. The internal uops get the pipelining advantages of RISC, while we get the encoding compression of a CISC instruction set.

gandalfgeek 6y ago

If you look at the latest ARM instruction sets they are not really "RISC". Sure, they're much saner than than the crazy legacy instructions that x86 carries, but still nowhere near a "real RISC" ISA as espoused by Hennessy and Patterson, the hallmarks of which are simple, orthogonal, atomic instructions, and a small number of them. Currently that is most closely embodied by RISC-V. If you look at how you can get computing gains going forward after the end of Moore's law, of course the glib answer is "parallelize across more cores!" but the more interesting path is to notice that behemoth single cores like x86 spend a ton of silicon area trying to optimize straight-line execution with things like speculative execution. If you saved all that silicon area, making each single core slower but smaller, but packed more cores on the die as a result, you would most likely come out faster. [1] [1]: https://science.sciencemag.org/content/368/6495/eaam9744/tab-pdf https://science.sciencemag.org/content/368/6495/eaam9744/tab...