4 ms·

>It started out being close to the metal but now it's an abstraction that can mislead you if you think processors are literally working the way x86 assembly des

by ksk 8y ago

>It started out being close to the metal but now it's an abstraction that can mislead you if you think processors are literally working the way x86 assembly describes. Well, the fact that we were able to abstract it out into an ISA, and still make progress would indicate that it isn't holding us back! >And surely the whole spectre issue could be lessened if we could be less reliant on CPUs having to guess what to keep in cache, which code paths are most likely, etc? Why would consumers purchase CPUs that performed worse? The only reason to use branch prediction is because it works and is a huge benefit.

inferiorhuman 8y ago
> Well, the fact that we were able to abstract it out into an ISA, and still make progress would indicate that it isn't holding us back! Just because something works doesn't mean it works well. Imagine if x86-64 ditched the variety of non-32/64-bit modes. Would x86 be able to better compete with ARM in power consumption?
- ksk 8y ago
  > Imagine if x86-64 ditched the variety of non-32/64-bit modes. Would x86 be able to better compete with ARM in power consumption? In what way? Do you mean instruction decoding? There is very little separation between x86 and ARM on that. x86 is optimized like crazy for the common instructions. https://en.wikipedia.org/wiki/CPU_cache#Micro-operation_(%CE%BCop_or_uop)_cache https://en.wikipedia.org/wiki/CPU_cache#Micro-operation_(%CE...
- BeeOnRope 8y ago
  Not really, those use a microscopic amount of area on a modern die and shouldn't have much power impact at all when they aren't being used. You could probably change the ISA in various ways to save power, or make other uarch or arch changes - but cutting out say the 16-bit modes isn't really one of them.
  - inferiorhuman 8y ago
    > You could probably change the ISA in various ways to save power, or make other uarch or arch changes - but cutting out say the 16-bit modes isn't really one of them. I've got no idea (obviously) but it seems that maintaining compatibility with legacy hardware shouldn't be all that cheap. If it is, kudos to Intel.
    - BeeOnRope 8y ago
      There was some point when it wasn't necessarily cheap: when chips had transistor counts in the hundreds of thousands or single digit millions. But current chips generally have billions of transistors (or at least high triple digit millions). There are just a huge number of gates to go around, and since the complexity of 16-bit support remains largely constant it becomes an ever-shrinking piece of the die. These backwards compatibility modes don't need to be super fast (after all, current chips are perhaps 1000x the speed of the old 16-bit chips), so they don't need to get a ton of gates thrown at them: they just need to work. If there were no backwards compatibility concerns, I'm sure Intel and AMD could like to get rid of this stuff: not so much because it uses a lot of space, but just because the design and validation effort to make sure these old ISAs keep working is probably considerable. It's the same kind of situation with all the old effectively obsolete instructions: supporting them takes minimal space, especially when they are allowed to be slow. The encoding space they take up is more of a problem - but that can't be changed now...
    - gpderetta 8y ago
      What I heard is that, by far, the biggest cost is validating the final hardware. Intel and AMD have very large experience and test tools so the incremental cost for a new CPU is not huge, but it is a big barrier for a new competitor in the x86 space (but then again, patents are probably an even bigger barrier). Newer/Simpler architectures should be easier to validate.
lmm 8y ago
Branch prediction is great except in the rare cases where it isn't. I wouldn't want to see it removed but I would like to see better documentation and a more transparent interface onto it, so that those rare programs that do need precise control over it (e.g. security code) can have it.
- ksk 8y ago
  >Branch prediction is great except in the rare cases where it isn't. Sure, is there any CPU feature that this does not apply to? >I wouldn't want to see it removed but I would like to see better documentation and a more transparent interface onto it, so that those rare programs that do need precise control over it (e.g. security code) can have it. Its hard to parse what your exact request is here. Branch predictors on various Intel/AMD/etc CPUs work slightly differently from each other, and so even if you had access to the design documents, you would have to write programs specific to each CPU instead of targeting x86/x86-64. Not to mention that microcode updates could alter the implementation. Or do you want to just disable it? But then there are other places where bugs can hide. DMA Controller bugs, side channel attacks on caches, or basic DRAM attacks like Row Hammer,etc. Letting external programmers access CPU internals is only going to open another HUGE can of worms.
  - lmm 8y ago
    > Branch predictors on various Intel/AMD/etc CPUs work slightly differently from each other, and so even if you had access to the design documents, you would have to write programs specific to each CPU instead of targeting x86/x86-64. Not to mention that microcode updates could alter the implementation. Sure, though hopefully that's something a compiler could do. What I'd like is to be able to write a compiler that could understand the difference between as-fast-as-possible code (most code) and constant-time code, and build the latter correctly. > But then there are other places where bugs can hide. DMA Controller bugs, side channel attacks on caches, or basic DRAM attacks like Row Hammer,etc. Letting external programmers access CPU internals is only going to open another HUGE can of worms. There are other holes, sure. That's not a reason not to fix the biggest hole. We'll fix the smaller holes in turn.

by ksk 8y ago

inferiorhuman 8y ago

> Well, the fact that we were able to abstract it out into an ISA, and still make progress would indicate that it isn't holding us back! Just because something works doesn't mean it works well. Imagine if x86-64 ditched the variety of non-32/64-bit modes. Would x86 be able to better compete with ARM in power consumption?

ksk 8y ago
> Imagine if x86-64 ditched the variety of non-32/64-bit modes. Would x86 be able to better compete with ARM in power consumption? In what way? Do you mean instruction decoding? There is very little separation between x86 and ARM on that. x86 is optimized like crazy for the common instructions. https://en.wikipedia.org/wiki/CPU_cache#Micro-operation_(%CE%BCop_or_uop)_cache https://en.wikipedia.org/wiki/CPU_cache#Micro-operation_(%CE...
BeeOnRope 8y ago
Not really, those use a microscopic amount of area on a modern die and shouldn't have much power impact at all when they aren't being used. You could probably change the ISA in various ways to save power, or make other uarch or arch changes - but cutting out say the 16-bit modes isn't really one of them.
- inferiorhuman 8y ago
  > You could probably change the ISA in various ways to save power, or make other uarch or arch changes - but cutting out say the 16-bit modes isn't really one of them. I've got no idea (obviously) but it seems that maintaining compatibility with legacy hardware shouldn't be all that cheap. If it is, kudos to Intel.
  - BeeOnRope 8y ago
    There was some point when it wasn't necessarily cheap: when chips had transistor counts in the hundreds of thousands or single digit millions. But current chips generally have billions of transistors (or at least high triple digit millions). There are just a huge number of gates to go around, and since the complexity of 16-bit support remains largely constant it becomes an ever-shrinking piece of the die. These backwards compatibility modes don't need to be super fast (after all, current chips are perhaps 1000x the speed of the old 16-bit chips), so they don't need to get a ton of gates thrown at them: they just need to work. If there were no backwards compatibility concerns, I'm sure Intel and AMD could like to get rid of this stuff: not so much because it uses a lot of space, but just because the design and validation effort to make sure these old ISAs keep working is probably considerable. It's the same kind of situation with all the old effectively obsolete instructions: supporting them takes minimal space, especially when they are allowed to be slow. The encoding space they take up is more of a problem - but that can't be changed now...
  - gpderetta 8y ago
    What I heard is that, by far, the biggest cost is validating the final hardware. Intel and AMD have very large experience and test tools so the incremental cost for a new CPU is not huge, but it is a big barrier for a new competitor in the x86 space (but then again, patents are probably an even bigger barrier). Newer/Simpler architectures should be easier to validate.

lmm 8y ago

Branch prediction is great except in the rare cases where it isn't. I wouldn't want to see it removed but I would like to see better documentation and a more transparent interface onto it, so that those rare programs that do need precise control over it (e.g. security code) can have it.

ksk 8y ago
>Branch prediction is great except in the rare cases where it isn't. Sure, is there any CPU feature that this does not apply to? >I wouldn't want to see it removed but I would like to see better documentation and a more transparent interface onto it, so that those rare programs that do need precise control over it (e.g. security code) can have it. Its hard to parse what your exact request is here. Branch predictors on various Intel/AMD/etc CPUs work slightly differently from each other, and so even if you had access to the design documents, you would have to write programs specific to each CPU instead of targeting x86/x86-64. Not to mention that microcode updates could alter the implementation. Or do you want to just disable it? But then there are other places where bugs can hide. DMA Controller bugs, side channel attacks on caches, or basic DRAM attacks like Row Hammer,etc. Letting external programmers access CPU internals is only going to open another HUGE can of worms.
- lmm 8y ago
  > Branch predictors on various Intel/AMD/etc CPUs work slightly differently from each other, and so even if you had access to the design documents, you would have to write programs specific to each CPU instead of targeting x86/x86-64. Not to mention that microcode updates could alter the implementation. Sure, though hopefully that's something a compiler could do. What I'd like is to be able to write a compiler that could understand the difference between as-fast-as-possible code (most code) and constant-time code, and build the latter correctly. > But then there are other places where bugs can hide. DMA Controller bugs, side channel attacks on caches, or basic DRAM attacks like Row Hammer,etc. Letting external programmers access CPU internals is only going to open another HUGE can of worms. There are other holes, sure. That's not a reason not to fix the biggest hole. We'll fix the smaller holes in turn.