4 ms·

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

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 5y 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 5y ago
  Intel and AMD CPUs have micro op caches for tight loops.
akira2501 5y 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 5y 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 5y 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_ 5y 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 5y 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/.

buildbot 5y 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 5y ago
Intel and AMD CPUs have micro op caches for tight loops.

akira2501 5y 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 5y 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 5y 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_ 5y 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 5y 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/.