5 ms·

Every time Intel has tried to more away from x86 (i960? Itanium? Maybe others...) they end up coming back. The years of backwards compatibility are a big sellin

by tyoma 7y ago

Every time Intel has tried to more away from x86 (i960? Itanium? Maybe others...) they end up coming back. The years of backwards compatibility are a big selling point.

wvenable 7y ago
There is value in the fact that the instruction set is an abstraction. CPU's built with more low-level instruction sets became obsolete faster because they couldn't adapt to new features and maintain compatibility as easily.
- setpatchaddress 7y ago
  Sounds like survivorship bias. x86's longevity is due to the amount of money thrown at the problem. You could surely start with a much cleaner instruction set like the M68k and wind up with a same-or-better result after spending billions on multiple projects to invent new ways of ameliorating the complexity of the ISA, some in parallel, over time. Or you can start by eliminating most of the decode complexity and not spend those billions, like ARM.
  - jcranmer 7y ago
    The decoder doesn't actually take all that much space in the hardware, though. It's going to be smaller than the normal OoO logic, which means it's a pretty minor tax at best for actual hardware.
    - baybal2 7y ago
      Saw die shots of Atom? Decoder makes more than half of the core, and there is no instruction cache. In a loop, you will be spending more joules on decoding than actual computations.
      - monocasa 7y ago
        What die shots are you looking at? I'm looking at a Silverthorne die and most of the frontend is taken up by the L1I$. https://en.wikichip.org/wiki/intel/microarchitectures/bonnell#Silverthorne https://en.wikichip.org/wiki/intel/microarchitectures/bonnel...
        baybal2 7y ago
        My bad
    - darkmighty 7y ago
      Instruction complexities can be used to save bandwidth/delay (and related energy consumption) at the cost of decoder size. Communication limitations are increasingly dominant in processors afaik; so the analysis is not so simple as to decoder size either.
      - jabl 7y ago
        Compressed RISC ISA's (e.g. RISC-V C extension) achieve density comparable to x86, with a much simpler decoder.
    - adwn 7y ago
      > It's going to be smaller than the normal OoO logic, which means it's a pretty minor tax at best for actual hardware. But it's a major tax for designing that hardware, and a potential source of bugs (the more complex, the more difficult to debug and verify).
  - spc476 7y ago
    As much as I like the M68k, I don't think it would be easy to extend it to 64 bits. I'm looking at the MOVE instruction, encoded as: 00ssRRRmmmMMMrrr ss = size 01 = 8 bits 10 = 32 bits 11 = 16 bits RRR = src register mmm = src mode MMM = dest mode rrr = dest register The obvious choice of setting the size bits to '00' for 64 bits is out of the question, because that overlaps many instructions (bit manipulations, bounds checking, several specialized move instructions). The whole instruction set is like this---where you would expect 64-bits to specified are a bunch of instructions instead.
cogman10 7y ago
I really wish Itanium had taken off. IMO it is a superior architecture that was simply ahead of it's time. Wouldn't it be great if software instead of hardware, had complete control of instruction ordering? Wouldn't it be great to not be limited by the current SIMD restrictions? Wouldn't it be nice if you could choose to spend more compile time to get even faster programs (vs relying on the hardware to do it JIT)? I mean, I get why it didn't happen. Stupid history chose wrong (Like making electrons have a negative charge).
- wolfgke 7y ago
  > I really wish Itanium had taken off. IMO it is a superior architecture that was simply ahead of it's time. Itanium was an architecture that was designed for "big iron", i.e. fast, powerful computers. It is thus, in my opinion, much harder to "scale down" to, say, mobile devices than x86.
  - unlinked_dll 7y ago
    x86 hasn't really proven that it scales down well for mobile devices either.
    - toast0 7y ago
      There are some x86 Android phones, and Windows 10 Mobile's Continuum looked designed to be run on an x86 phone, but Intel killed that line of processors before Microsoft built a device.
    - wolfgke 7y ago
      Intel produced SoCs for mobile devices, concretely Speatrum SC9853i and Spreadtrum SC9861G-IA. If you want to scale even further down, consider Intel Quark (https://en.wikipedia.org/wiki/Intel_Quark https://en.wikipedia.org/wiki/Intel_Quark). For an analysis why it failed in the market, consider http://linuxgizmos.com/who-killed-the-quark/ http://linuxgizmos.com/who-killed-the-quark/ To me, it seems that the central reason why these chips failed commercially is that at the lower end, SoCs offer a much thinner margins than CPUs for laptops, desktop PCs and servers.
NPC32419419 7y ago
Intel did not create x86_64. AMD did.

by tyoma 7y ago

Every time Intel has tried to more away from x86 (i960? Itanium? Maybe others...) they end up coming back. The years of backwards compatibility are a big selling point.

wvenable 7y ago

There is value in the fact that the instruction set is an abstraction. CPU's built with more low-level instruction sets became obsolete faster because they couldn't adapt to new features and maintain compatibility as easily.

setpatchaddress 7y ago
Sounds like survivorship bias. x86's longevity is due to the amount of money thrown at the problem. You could surely start with a much cleaner instruction set like the M68k and wind up with a same-or-better result after spending billions on multiple projects to invent new ways of ameliorating the complexity of the ISA, some in parallel, over time. Or you can start by eliminating most of the decode complexity and not spend those billions, like ARM.
- jcranmer 7y ago
  The decoder doesn't actually take all that much space in the hardware, though. It's going to be smaller than the normal OoO logic, which means it's a pretty minor tax at best for actual hardware.
  - baybal2 7y ago
    Saw die shots of Atom? Decoder makes more than half of the core, and there is no instruction cache. In a loop, you will be spending more joules on decoding than actual computations.
    - monocasa 7y ago
      What die shots are you looking at? I'm looking at a Silverthorne die and most of the frontend is taken up by the L1I$. https://en.wikichip.org/wiki/intel/microarchitectures/bonnell#Silverthorne https://en.wikichip.org/wiki/intel/microarchitectures/bonnel...
      - baybal2 7y ago
        My bad
  - darkmighty 7y ago
    Instruction complexities can be used to save bandwidth/delay (and related energy consumption) at the cost of decoder size. Communication limitations are increasingly dominant in processors afaik; so the analysis is not so simple as to decoder size either.
    - jabl 7y ago
      Compressed RISC ISA's (e.g. RISC-V C extension) achieve density comparable to x86, with a much simpler decoder.
  - adwn 7y ago
    > It's going to be smaller than the normal OoO logic, which means it's a pretty minor tax at best for actual hardware. But it's a major tax for designing that hardware, and a potential source of bugs (the more complex, the more difficult to debug and verify).
- spc476 7y ago
  As much as I like the M68k, I don't think it would be easy to extend it to 64 bits. I'm looking at the MOVE instruction, encoded as: 00ssRRRmmmMMMrrr ss = size 01 = 8 bits 10 = 32 bits 11 = 16 bits RRR = src register mmm = src mode MMM = dest mode rrr = dest register The obvious choice of setting the size bits to '00' for 64 bits is out of the question, because that overlaps many instructions (bit manipulations, bounds checking, several specialized move instructions). The whole instruction set is like this---where you would expect 64-bits to specified are a bunch of instructions instead.

cogman10 7y ago

I really wish Itanium had taken off. IMO it is a superior architecture that was simply ahead of it's time. Wouldn't it be great if software instead of hardware, had complete control of instruction ordering? Wouldn't it be great to not be limited by the current SIMD restrictions? Wouldn't it be nice if you could choose to spend more compile time to get even faster programs (vs relying on the hardware to do it JIT)? I mean, I get why it didn't happen. Stupid history chose wrong (Like making electrons have a negative charge).

wolfgke 7y ago
> I really wish Itanium had taken off. IMO it is a superior architecture that was simply ahead of it's time. Itanium was an architecture that was designed for "big iron", i.e. fast, powerful computers. It is thus, in my opinion, much harder to "scale down" to, say, mobile devices than x86.
- unlinked_dll 7y ago
  x86 hasn't really proven that it scales down well for mobile devices either.
  - toast0 7y ago
    There are some x86 Android phones, and Windows 10 Mobile's Continuum looked designed to be run on an x86 phone, but Intel killed that line of processors before Microsoft built a device.
  - wolfgke 7y ago
    Intel produced SoCs for mobile devices, concretely Speatrum SC9853i and Spreadtrum SC9861G-IA. If you want to scale even further down, consider Intel Quark (https://en.wikipedia.org/wiki/Intel_Quark https://en.wikipedia.org/wiki/Intel_Quark). For an analysis why it failed in the market, consider http://linuxgizmos.com/who-killed-the-quark/ http://linuxgizmos.com/who-killed-the-quark/ To me, it seems that the central reason why these chips failed commercially is that at the lower end, SoCs offer a much thinner margins than CPUs for laptops, desktop PCs and servers.

NPC32419419 7y ago

Intel did not create x86_64. AMD did.