3 ms·

Screw that; I want them to dump x86 altogether and move to ARM, or maybe come up with something even better, to compete with Apple's M2. Why are we stuck with

Screw that; I want them to dump x86 altogether and move to ARM, or maybe come up with something even better, to compete with Apple's M2. Why are we stuck with this shitty old ISA from the 1970s?

jeroenhd 4y ago
ARM came out the same year as 32 bit x86. Both architectures are very old. I very much doubt that architecture is all that relevant for their advancements in power usage. Apple's chips contain a significant x86 feature without ruining battery life. Meanwhile, Qualcom is struggling to compete with Apple in both performance and efficiency despite being in the ARM space for much longer. I'm sure if Apple could've gotten an x64 license ten years ago, they would've made their own x64 chips instead of switching to ARM. When Apple's plans started coming together, there simply were no competing architectures they could base their chips on. MIPS was practically dead already, x64 was extremely closed off, RISC-V wasn't even announced and struggles to keep up today and it wasn't even announced when Apple started selling their own chips. Maybe they could've licensed POWER6 or an early version of POWER7? The POWER architecture isn't exactly widely used or designed to be power efficient; power management wasn't introduced until 2017 and even then it was optional. There simply weren't any serious alternatives to licensing ARM and Apple would be stupid to develop an entirely separate CPU architecture for their desktop/laptop/tablet form factors.
- wkat4242 4y ago
  It would have been pretty cool if they'd gone back to the Power platform though. Full circle.
thowieruo2343 4y ago
... because we're stuck with the shitty programming languages and development paradigms from the 1970s.
kibwen 4y ago
> Why are we stuck with this shitty old ISA from the 1970s? ARM is from the 1980s, let's just jump right to RISC-V instead. :)
moonchild 4y ago
The pc platform is standardised and open. Everything else is a fragmentary shitshow. It will clearly be superseded at some point, but I pray it takes its time.
dehrmann 4y ago
These days, don't instruction sets just map to "real" instructions on the chip? Something about microcode. Clearly, I'm not a chip engineer.
- adwn 4y ago
  Yes and no. The (very simplified) answer is that yes, some ISA (front-end) instructions are decoded into simpler back-end operations, but the design of the ISA still imposes constraints on the implementation of that decoder [1] and on the design of the back-end. Then there are concerns like register pressure. x86 has so few general purpose registers, that values need to be stored on the stack and reloaded when needed. Some of the performance impact can be reduced by complex decoder logic, but making complex logic fast nearly always leads to high power consumption. [1] E.g., the highly variable length of x86/x86-64 instructions puts a limit on the number of instructions that can be decoded per cycle.
  - peterfirefly 4y ago
    > x86 has so few general purpose registers, It's got plenty in 64-bit mode (15 + RSP) + you can spill to SSE registers instead of the stack. It also needs fewer registers than (most) RISCs because it has a more flexible way of specifying memory addresses (base, index, scale, offset + PC-relative) and it also has proper immediates. > the highly variable length of x86/x86-64 instructions puts a limit on the number of instructions that can be decoded per cycle. Not that much of a limit, actually. Yes, a parallel decoder that takes on arbitrary byte sequence and decodes them is hard to scale up. The instruction lengths can be cached, though. In fact, they used to be cached as extra bits in L1 back when the size of a wide decoder was a significant size of the CPU transistor budget. It should be possible to use that idea again to go wider. The newer x86 CPU's also have a µop cache so no decoding is even needed for tight loops.
nly 4y ago
Decades of binary compatibility without concern for emulation bugs?

Screw that; I want them to dump x86 altogether and move to ARM, or maybe come up with something even better, to compete with Apple's M2. Why are we stuck with this shitty old ISA from the 1970s?

jeroenhd 4y ago

ARM came out the same year as 32 bit x86. Both architectures are very old. I very much doubt that architecture is all that relevant for their advancements in power usage. Apple's chips contain a significant x86 feature without ruining battery life. Meanwhile, Qualcom is struggling to compete with Apple in both performance and efficiency despite being in the ARM space for much longer. I'm sure if Apple could've gotten an x64 license ten years ago, they would've made their own x64 chips instead of switching to ARM. When Apple's plans started coming together, there simply were no competing architectures they could base their chips on. MIPS was practically dead already, x64 was extremely closed off, RISC-V wasn't even announced and struggles to keep up today and it wasn't even announced when Apple started selling their own chips. Maybe they could've licensed POWER6 or an early version of POWER7? The POWER architecture isn't exactly widely used or designed to be power efficient; power management wasn't introduced until 2017 and even then it was optional. There simply weren't any serious alternatives to licensing ARM and Apple would be stupid to develop an entirely separate CPU architecture for their desktop/laptop/tablet form factors.

wkat4242 4y ago
It would have been pretty cool if they'd gone back to the Power platform though. Full circle.

thowieruo2343 4y ago

... because we're stuck with the shitty programming languages and development paradigms from the 1970s.

kibwen 4y ago

> Why are we stuck with this shitty old ISA from the 1970s? ARM is from the 1980s, let's just jump right to RISC-V instead. :)

moonchild 4y ago

The pc platform is standardised and open. Everything else is a fragmentary shitshow. It will clearly be superseded at some point, but I pray it takes its time.

dehrmann 4y ago

These days, don't instruction sets just map to "real" instructions on the chip? Something about microcode. Clearly, I'm not a chip engineer.

adwn 4y ago
Yes and no. The (very simplified) answer is that yes, some ISA (front-end) instructions are decoded into simpler back-end operations, but the design of the ISA still imposes constraints on the implementation of that decoder [1] and on the design of the back-end. Then there are concerns like register pressure. x86 has so few general purpose registers, that values need to be stored on the stack and reloaded when needed. Some of the performance impact can be reduced by complex decoder logic, but making complex logic fast nearly always leads to high power consumption. [1] E.g., the highly variable length of x86/x86-64 instructions puts a limit on the number of instructions that can be decoded per cycle.
- peterfirefly 4y ago
  > x86 has so few general purpose registers, It's got plenty in 64-bit mode (15 + RSP) + you can spill to SSE registers instead of the stack. It also needs fewer registers than (most) RISCs because it has a more flexible way of specifying memory addresses (base, index, scale, offset + PC-relative) and it also has proper immediates. > the highly variable length of x86/x86-64 instructions puts a limit on the number of instructions that can be decoded per cycle. Not that much of a limit, actually. Yes, a parallel decoder that takes on arbitrary byte sequence and decodes them is hard to scale up. The instruction lengths can be cached, though. In fact, they used to be cached as extra bits in L1 back when the size of a wide decoder was a significant size of the CPU transistor budget. It should be possible to use that idea again to go wider. The newer x86 CPU's also have a µop cache so no decoding is even needed for tight loops.

nly 4y ago

Decades of binary compatibility without concern for emulation bugs?