5 ms·

I wouldn't say the x86 is the weirdo in these cases, it's just not a RISC.

by aap_ 4y ago

lynguist 4y ago
In essence, it is a RISC since the days of Pentium Pro. Each instruction is decoded to several micro-operations and the trick of making the CPU run fast lies in the decoder. This also leads to situations where many instructions in x86 asm will run faster than fewer complex instructions which the decoder may not decode to its most optimal micro-operations sequence.
- phamilton 4y ago
  To what extent is the decoding consistent? It always felt weird to me that we'd do something in hardware on every execution that could be done once in software at compile time. But if the decoder does smart things that would make more sense to me. For example, with SMT the decoder could choose not to use certain ops if the compute units are in use by the other thread.
  - buildbot 4y ago
    I am not sure of any arch that does this, but having a second stage decode buys 2 things off the top of my head - better instruction cache usage, esp. for small loops, and the flexibility to decode ops differently on different versions of the same arch from one binary. Otherwise you would have to have tons of different versions for each flavor of x86 out there.
    - imtringued 4y ago
      Intel and AMD CPUs have micro op caches for tight loops.
  - akira2501 4y ago
    > on every execution that could be done once in software at compile time Which is to me, essentially, VLIW. Those architectures didn't work out very well. There's a lot of memory pressure just to move instructions around and the costs didn't seem to outweigh the benefits.
    - phamilton 4y ago
      The Mill CPU and architecture is a fascinating approach here. Who knows if we'll ever see a real piece of hardware from them, but as I understand it they require a compiler tuned to the exact cpu model to maximize on-die memory and other aspects.
  - gpderetta 4y ago
    It is very inconsistent between major microarchitectural revisions, sometimes even between me minor steppings. Sometimes firmware updates can change the decoding (usually to fix bugs).
    - Jasper_ 4y ago
      The firmware can only do this by turning on an extremely slow fallback path. It's not common and it's seen as an avenue of last resort.
  - astrange 4y ago
    That post isn't true, common instructions only take a few µops (or even one) and the main difference is register renaming. Microcoding mainly lets them support old and very complicated instructions that nobody actually needs to be fast. You can see instruction latencies at https://www.agner.org/optimize/ https://www.agner.org/optimize/.
- saagarjha 4y ago
  No, this take is incorrect. x86-64 instructions do get lowered into µops, but all the common ones will only execute one, or maybe two. The real win for µops is letting Intel microcode instructions that nobody cares about, but you really shouldn't be using them anyways.
- aap_ 4y ago
  That's an implementation detail. The submission was about architecture.
marcosdumay 4y ago
Notice that it's the only one remaining? Yes, it's a weirdo.
- FullyFunctional 4y ago
  Not defending the weirdo, but IBM Z is a thing that is shipping, heavily used, and still evolving. It's more CISC than even x86. I do find it sad that we are stuck in an 80 year old paradigm that is a horrible fit for how CPUs are actually implemented in 2022, but the inertia is a strong in this one.
  - kosherhurricane 4y ago
    Inertia is the same as backward compatibility. Kinda like gas engines and fuel pumps. Or wall socket formats. Inertia.
    - FullyFunctional 4y ago
      I think you are illustrating my point, thanks. Gas engines are surely but slowly being replaced with much better, cleaner, and more efficient alternatives. Wall socket formats are there to stay but increasingly low DC loads are coalescing around USB, with USB-C really accelerating the change. So yes, we can overcome inertia, it just take a lot of energy.
- DaiPlusPlus 4y ago
  > Notice that it's the only one remaining? Motorola 68K is still around too.
- aap_ 4y ago
  You mean as opposed to the other architectures mentioned in the article? ppc, mips, itanium and alpha. Two of which are utterly dead, one of which looks like it's dying (mips) and one that is little more than a niche product (ppc).
  - 4y ago
zwieback 4y ago
Came here to say that. At the time the post was written it was really just comparing x86 to the already dying RISC. Nowadays that comparison makes even less sense as the two schools of thought have more or less converged.

I wouldn't say the x86 is the weirdo in these cases, it's just not a RISC.

by aap_ 4y ago

I wouldn't say the x86 is the weirdo in these cases, it's just not a RISC.

In essence, it is a RISC since the days of Pentium Pro. Each instruction is decoded to several micro-operations and the trick of making the CPU run fast lies in the decoder. This also leads to situations where many instructions in x86 asm will run faster than fewer complex instructions which the decoder may not decode to its most optimal micro-operations sequence.

phamilton 4y ago
To what extent is the decoding consistent? It always felt weird to me that we'd do something in hardware on every execution that could be done once in software at compile time. But if the decoder does smart things that would make more sense to me. For example, with SMT the decoder could choose not to use certain ops if the compute units are in use by the other thread.
- buildbot 4y ago
  I am not sure of any arch that does this, but having a second stage decode buys 2 things off the top of my head - better instruction cache usage, esp. for small loops, and the flexibility to decode ops differently on different versions of the same arch from one binary. Otherwise you would have to have tons of different versions for each flavor of x86 out there.
  - imtringued 4y ago
    Intel and AMD CPUs have micro op caches for tight loops.
- akira2501 4y ago
  > on every execution that could be done once in software at compile time Which is to me, essentially, VLIW. Those architectures didn't work out very well. There's a lot of memory pressure just to move instructions around and the costs didn't seem to outweigh the benefits.
  - phamilton 4y ago
    The Mill CPU and architecture is a fascinating approach here. Who knows if we'll ever see a real piece of hardware from them, but as I understand it they require a compiler tuned to the exact cpu model to maximize on-die memory and other aspects.
- gpderetta 4y ago
  It is very inconsistent between major microarchitectural revisions, sometimes even between me minor steppings. Sometimes firmware updates can change the decoding (usually to fix bugs).
  - Jasper_ 4y ago
    The firmware can only do this by turning on an extremely slow fallback path. It's not common and it's seen as an avenue of last resort.
- astrange 4y ago
  That post isn't true, common instructions only take a few µops (or even one) and the main difference is register renaming. Microcoding mainly lets them support old and very complicated instructions that nobody actually needs to be fast. You can see instruction latencies at https://www.agner.org/optimize/ https://www.agner.org/optimize/.
saagarjha 4y ago
No, this take is incorrect. x86-64 instructions do get lowered into µops, but all the common ones will only execute one, or maybe two. The real win for µops is letting Intel microcode instructions that nobody cares about, but you really shouldn't be using them anyways.
aap_ 4y ago
That's an implementation detail. The submission was about architecture.

marcosdumay 4y ago

Notice that it's the only one remaining? Yes, it's a weirdo.

FullyFunctional 4y ago
Not defending the weirdo, but IBM Z is a thing that is shipping, heavily used, and still evolving. It's more CISC than even x86. I do find it sad that we are stuck in an 80 year old paradigm that is a horrible fit for how CPUs are actually implemented in 2022, but the inertia is a strong in this one.
- kosherhurricane 4y ago
  Inertia is the same as backward compatibility. Kinda like gas engines and fuel pumps. Or wall socket formats. Inertia.
  - FullyFunctional 4y ago
    I think you are illustrating my point, thanks. Gas engines are surely but slowly being replaced with much better, cleaner, and more efficient alternatives. Wall socket formats are there to stay but increasingly low DC loads are coalescing around USB, with USB-C really accelerating the change. So yes, we can overcome inertia, it just take a lot of energy.
DaiPlusPlus 4y ago
> Notice that it's the only one remaining? Motorola 68K is still around too.
aap_ 4y ago
You mean as opposed to the other architectures mentioned in the article? ppc, mips, itanium and alpha. Two of which are utterly dead, one of which looks like it's dying (mips) and one that is little more than a niche product (ppc).
- 4y ago

zwieback 4y ago

Came here to say that. At the time the post was written it was really just comparing x86 to the already dying RISC. Nowadays that comparison makes even less sense as the two schools of thought have more or less converged.