3 ms·

All the moving pieces in Intel x86-to-RISC decoding (instruction decoder, μop cache, Microcode Sequencer ROM...) use up a non-trivial amount of silicon and powe

All the moving pieces in Intel x86-to-RISC decoding (instruction decoder, μop cache, Microcode Sequencer ROM...) use up a non-trivial amount of silicon and power.

makapuf 7y ago
I'm not sure. If that were the case why wouldn't intel expose a native, better fit to uops instruction set in addition to the legacy, difficult to decode one and let the apps use the newer ones (or the subset of existing ones which do map well)?
- umanwizard 7y ago
  My guess is (1) inertia, and (2) not wanting to commit to a specific instruction set because they tweak the internal μop set with every release. And (3), this would add complexity, because, even though one is much simpler, now you need two completely separate decoding pipelines and mechanisms for switching between them.
  - makapuf 7y ago
    Can't argue with 1. For 2 it's still an instruction set separate from uops so you might not be as sensitive to changes you still get a level of indirection. For 3 .. it depends. You might gain in power if you use the newer one more and you might as well make the older one simpler to achieve 90% of speed maybe. But maybe the decoding of instructions that counts is not that expensive compared to OOO branch predictors and 512 bits ALUs
acdha 7y ago
Yes, it’s more than zero but you have to look at that as part of the entire chip budget. For example, this USENIX paper estimates 3-10% on power: https://www.usenix.org/system/files/conference/cooldc16/cooldc16-paper-hirki.pdf https://www.usenix.org/system/files/conference/cooldc16/cool... That’s not nothing but usually when people talk about this the rhetoric assume it’s much greater and that e.g. ARM doesn’t have similar issues supporting its older instructions, albeit at smaller scale. If you look at the results, and a couple decades where everyone else was struggling to match X86 on either performance or non-embedded power efficiency, it clearly wasn’t holding them back that much. Even Intel’s huge moon-shot clean architecture failed to outperform despite starting with considerable experience and no legacy baggage.

All the moving pieces in Intel x86-to-RISC decoding (instruction decoder, μop cache, Microcode Sequencer ROM...) use up a non-trivial amount of silicon and power.

makapuf 7y ago

I'm not sure. If that were the case why wouldn't intel expose a native, better fit to uops instruction set in addition to the legacy, difficult to decode one and let the apps use the newer ones (or the subset of existing ones which do map well)?

umanwizard 7y ago
My guess is (1) inertia, and (2) not wanting to commit to a specific instruction set because they tweak the internal μop set with every release. And (3), this would add complexity, because, even though one is much simpler, now you need two completely separate decoding pipelines and mechanisms for switching between them.
- makapuf 7y ago
  Can't argue with 1. For 2 it's still an instruction set separate from uops so you might not be as sensitive to changes you still get a level of indirection. For 3 .. it depends. You might gain in power if you use the newer one more and you might as well make the older one simpler to achieve 90% of speed maybe. But maybe the decoding of instructions that counts is not that expensive compared to OOO branch predictors and 512 bits ALUs

acdha 7y ago

Yes, it’s more than zero but you have to look at that as part of the entire chip budget. For example, this USENIX paper estimates 3-10% on power: https://www.usenix.org/system/files/conference/cooldc16/cooldc16-paper-hirki.pdf https://www.usenix.org/system/files/conference/cooldc16/cool... That’s not nothing but usually when people talk about this the rhetoric assume it’s much greater and that e.g. ARM doesn’t have similar issues supporting its older instructions, albeit at smaller scale. If you look at the results, and a couple decades where everyone else was struggling to match X86 on either performance or non-embedded power efficiency, it clearly wasn’t holding them back that much. Even Intel’s huge moon-shot clean architecture failed to outperform despite starting with considerable experience and no legacy baggage.