8 ms·

I wonder if the history of x86 is holding us back in a big way. It started out being close to the metal but now it's an abstraction that can mislead you if you

I wonder if the history of x86 is holding us back in a big way. 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. 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?

krylon 8y ago
Well, Intel has tried repeatedly to replace x86 (AXP32, i860/i960, Itanium), but in a way, they were a victim of their own success.
- jecel 8y ago
  Actually, the iAPX432 came first in 1976. When it became obvious that this project was going to take longer than expected (it was only launched in 1981) Intel did a quick extension to the 8080 to keep customers from going to the competition while they waited.
  - krylon 8y ago
    Thank you for pointing that out!
convolvatron 8y ago
there was at least one non-realized research project where the cache was exposed as part of the architecture to be managed by the compiler (ppc lets you do some of that). i think thats a potentially very fruitful approach, but would it have helped the spectre situation in any way? oh, what you're suggesting in an analog for compiler driven speculation? that may have helped, and is also probably worth thinking about
- ryanianian 8y ago
  > but would it have helped the spectre situation in any way? Presumably a compiler could put cache-lookups and/or cache-waits in non-predictably (perhaps choosing to do so when it suspects a cache-miss anyway).
- xenadu02 8y ago
  Every single CPU architecture that has decided to lean on "smart compilers" has failed. Intel flushed billions down the drain on Itanium. They lit $100 bills on fire trying to make a smart compiler. It never paid off. Think about that for a minute. No matter how good your compiler I'll put my money on using hardware to solve Spectre. In the future I'd expect caches to gain some kind of exclusive tagging or set-aside a per-core reorder area. Fetches will have to go there until the instruction that performed the fetch is retired successfully, then the entry can be made visible. Other threads or cores won't observe any changes to cache state based on speculative execution. It will be complicated, cost some transistors, and have a minor but measurable performance impact. The perf impact being having to fetch the same memory address multiple times, possibly all the way from RAM, because the instruction that fetched it before you hasn't retired yet. I don't know what impact that will have on cache traffic. If we're all very lucky, it won't be possible to use L3/L2 as side channels and we can ignore them (we probably aren't that lucky).
  - pjmlp 8y ago
    I just read Microsoft is having their own go at it. https://www.theregister.co.uk/2018/06/18/microsoft_e2_edge_windows_10/ https://www.theregister.co.uk/2018/06/18/microsoft_e2_edge_w...
ahartmetz 8y ago
Speculation has nothing to do with x86 in particular, although it has something to do with its general approach to execution (as opposed to e.g. the Mill CPU). Speculation is part of out of order execution, which is logic to execute code passages when their inputs are ready, as opposed to strictly in program order, while maintaining the program visible effects of executing in program order. It works the same in ARM, MIPS etc. Not doing OOO execution roughly halves CPU throughput on your average code. AFAIK OOO without speculation is possible, but loses maybe half of its efficacy. Actual experts may want to correct my numbers.
kowdermeister 8y ago
I already posted about WebAssembly in this thread and I think you are correct. It looks completely different than anything else before. I can see functional languages targeting it directly.
digi_owl 8y ago
These days there are an absurd number of abstraction layers in any computing stack. Fire up anything electron based, and you are looking at scripts being JITed inside a "VM", sitting on top of an OS that abstract away the hardware, sitting on top of hardware that is pretending to be something from the 80s/90s.
- Koshkin 8y ago
  > electron based Electrons are arguably at the very base of the whole pyramid (I know, I know :). But then again, there's these pieces of Si pretending to be transistors, etc...
jeffwass 8y ago
As someone who hasn’t written assembly in 20+ yrs (some 68k back then, and bits of z80), I’m curious about some examples of how the assembly abstraction diverges from the underlying processor.
- MechanicalTwerk 8y ago
  https://news.ycombinator.com/item?id=9264195 https://news.ycombinator.com/item?id=9264195
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.
blattimwind 8y ago
> I wonder if the history of x86 is holding us back in a big way. 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. But when you compare high-end cores, you always see the same picture, regardless of ISA. Large surface area (~1/3 of the core) used for insn fetch/decode/schedule; they look all the same, whether it's POWERn or the latest Sandy-Bridge/Haswell rehash... people claim that other ISAs would be a lot easier/faster/more efficient to decode, but that doesn't seem to be true in practice. It seems to me that any difference that might be there gets dwarfed by the sheer complexity of OoOE and speculative execution. What we do know is outside some niches (like DSPs, where VLIW reigns king) static techniques essentially do not work for application code, because it's impossible to predict statically.
- thechao 8y ago
  Even 15 decoders are a pinprick on the core’s area—at least when I saw die area for LRB. Fetch & schedule we’re a bit larger. Most of the core area was register files & floating-vector logic.
  - bogomipz 8y ago
    >."..at least when I saw die area for LRB" What is LRB?
    - woadwarrior01 8y ago
      Probably Larrabee, Intel’s cancelled GPGPU with an x86 ISA.
  - brandmeyer 8y ago
    In fairness, Larrabee was originally an in-order design.
    - gpderetta 8y ago
      It was also a simpler core, which means that for a complex OoO monster, the decoder would be an even smaller area. The OoO instruction scheduler would be a significant chunk, but that has nothing to do with being x86.
Pica_soO 8y ago
Intel abandoned it themselves, internally? The whole concept of backwards compatibility to a extensive library of old fixed functions was give up about 10 years gao. All that remains is a bw-compatible Assembly-API and whatever proprietary happens to the microcode generated from this.
xenadu02 8y ago
Nope. x86 decode to micro-ops is a trivial amount of die. It is constant (not completely true but true enough for all useful purposes) while transistor count has gone through many doublings. In some cases x86 is a slight win, as it can function as a form of instruction compression, slightly reducing i-cache pressure. There may be architectural limitations (like strong store ordering) that are relevant but in practice it hasn't made a huge difference.

krylon 8y ago

Well, Intel has tried repeatedly to replace x86 (AXP32, i860/i960, Itanium), but in a way, they were a victim of their own success.

jecel 8y ago
Actually, the iAPX432 came first in 1976. When it became obvious that this project was going to take longer than expected (it was only launched in 1981) Intel did a quick extension to the 8080 to keep customers from going to the competition while they waited.
- krylon 8y ago
  Thank you for pointing that out!

convolvatron 8y ago

there was at least one non-realized research project where the cache was exposed as part of the architecture to be managed by the compiler (ppc lets you do some of that). i think thats a potentially very fruitful approach, but would it have helped the spectre situation in any way? oh, what you're suggesting in an analog for compiler driven speculation? that may have helped, and is also probably worth thinking about

ryanianian 8y ago
> but would it have helped the spectre situation in any way? Presumably a compiler could put cache-lookups and/or cache-waits in non-predictably (perhaps choosing to do so when it suspects a cache-miss anyway).
xenadu02 8y ago
Every single CPU architecture that has decided to lean on "smart compilers" has failed. Intel flushed billions down the drain on Itanium. They lit $100 bills on fire trying to make a smart compiler. It never paid off. Think about that for a minute. No matter how good your compiler I'll put my money on using hardware to solve Spectre. In the future I'd expect caches to gain some kind of exclusive tagging or set-aside a per-core reorder area. Fetches will have to go there until the instruction that performed the fetch is retired successfully, then the entry can be made visible. Other threads or cores won't observe any changes to cache state based on speculative execution. It will be complicated, cost some transistors, and have a minor but measurable performance impact. The perf impact being having to fetch the same memory address multiple times, possibly all the way from RAM, because the instruction that fetched it before you hasn't retired yet. I don't know what impact that will have on cache traffic. If we're all very lucky, it won't be possible to use L3/L2 as side channels and we can ignore them (we probably aren't that lucky).
- pjmlp 8y ago
  I just read Microsoft is having their own go at it. https://www.theregister.co.uk/2018/06/18/microsoft_e2_edge_windows_10/ https://www.theregister.co.uk/2018/06/18/microsoft_e2_edge_w...

ahartmetz 8y ago

Speculation has nothing to do with x86 in particular, although it has something to do with its general approach to execution (as opposed to e.g. the Mill CPU). Speculation is part of out of order execution, which is logic to execute code passages when their inputs are ready, as opposed to strictly in program order, while maintaining the program visible effects of executing in program order. It works the same in ARM, MIPS etc. Not doing OOO execution roughly halves CPU throughput on your average code. AFAIK OOO without speculation is possible, but loses maybe half of its efficacy. Actual experts may want to correct my numbers.

kowdermeister 8y ago

I already posted about WebAssembly in this thread and I think you are correct. It looks completely different than anything else before. I can see functional languages targeting it directly.

digi_owl 8y ago

These days there are an absurd number of abstraction layers in any computing stack. Fire up anything electron based, and you are looking at scripts being JITed inside a "VM", sitting on top of an OS that abstract away the hardware, sitting on top of hardware that is pretending to be something from the 80s/90s.

Koshkin 8y ago
> electron based Electrons are arguably at the very base of the whole pyramid (I know, I know :). But then again, there's these pieces of Si pretending to be transistors, etc...

jeffwass 8y ago

As someone who hasn’t written assembly in 20+ yrs (some 68k back then, and bits of z80), I’m curious about some examples of how the assembly abstraction diverges from the underlying processor.

MechanicalTwerk 8y ago
https://news.ycombinator.com/item?id=9264195 https://news.ycombinator.com/item?id=9264195

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.

blattimwind 8y ago

> I wonder if the history of x86 is holding us back in a big way. 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. But when you compare high-end cores, you always see the same picture, regardless of ISA. Large surface area (~1/3 of the core) used for insn fetch/decode/schedule; they look all the same, whether it's POWERn or the latest Sandy-Bridge/Haswell rehash... people claim that other ISAs would be a lot easier/faster/more efficient to decode, but that doesn't seem to be true in practice. It seems to me that any difference that might be there gets dwarfed by the sheer complexity of OoOE and speculative execution. What we do know is outside some niches (like DSPs, where VLIW reigns king) static techniques essentially do not work for application code, because it's impossible to predict statically.

thechao 8y ago
Even 15 decoders are a pinprick on the core’s area—at least when I saw die area for LRB. Fetch & schedule we’re a bit larger. Most of the core area was register files & floating-vector logic.
- bogomipz 8y ago
  >."..at least when I saw die area for LRB" What is LRB?
  - woadwarrior01 8y ago
    Probably Larrabee, Intel’s cancelled GPGPU with an x86 ISA.
- brandmeyer 8y ago
  In fairness, Larrabee was originally an in-order design.
  - gpderetta 8y ago
    It was also a simpler core, which means that for a complex OoO monster, the decoder would be an even smaller area. The OoO instruction scheduler would be a significant chunk, but that has nothing to do with being x86.

Pica_soO 8y ago

Intel abandoned it themselves, internally? The whole concept of backwards compatibility to a extensive library of old fixed functions was give up about 10 years gao. All that remains is a bw-compatible Assembly-API and whatever proprietary happens to the microcode generated from this.

xenadu02 8y ago

Nope. x86 decode to micro-ops is a trivial amount of die. It is constant (not completely true but true enough for all useful purposes) while transistor count has gone through many doublings. In some cases x86 is a slight win, as it can function as a form of instruction compression, slightly reducing i-cache pressure. There may be architectural limitations (like strong store ordering) that are relevant but in practice it hasn't made a huge difference.