7 ms·

Intel is dying under the weight of its own technical debt. AMD will eventually have this problem too as ARM catches up. Meanwhile, it's 2020 and and x86 instr

Intel is dying under the weight of its own technical debt. AMD will eventually have this problem too as ARM catches up. Meanwhile, it's 2020 and and x86 instruction sets upgrades are infrequent compared to ARM. And x86 CPUs still are required to support 16-bit devices from 35 years ago.

tenebrisalietum 6y ago
> And x86 CPUs still are required to support 16-bit devices from 35 years ago. I heard somewhere that this year Intel was going to begin to phase out support for BIOS, which would allow Intel to eliminate CPUs booting up in "real mode". I think as long as plain PCI is something supported, some sort of 16-bit support has to be in the firmware because of option ROMs. Though I'm not sure UEFI couldn't service those with some sort of emulation layer (may as well, UEFI's already complex enough).
throwaway2048 6y ago
Intel (and AMD's) problems have nothing to do with any supposed "technical debt" imposed by x86. Also, the x86 instruction set gets upgraded with practically every single generation of Intel and AMD processor.
- bcatanzaro 6y ago
  ARM is very old as well and has plenty of technical debt. RISCV, on the other hand...
  - mikece 6y ago
    What do you suppose the chances are of Apple compiling/running iOS and macOC on RISCV?
    - pram 6y ago
      zero percent
    - dathinab 6y ago
      Closer to zero, it's an open architecture something the king of walled gardens wouldn't touch from a mile away. ;=) Jokes aside the real reason why it's extremely unlikely is that they put a lot of money into ARM and they simply have no reason to switch to it. For this to happen ARM would need to do something like massively increase the price of their IP licenses, or simila. Which won't happen.
    - monocasa 6y ago
      Apple has even a less incentive then most to support RISC-V versus ARM. They were a super early investor in ARM back in the early 90s (to the point where ARM probably wouldn't exist today without Apple). I'd be surprised if they pay more than a token amount for their core licenses. For all intents and purposes, RISC-V being open just puts it on the same footing for Apple as ARM is for them.
  - monocasa 6y ago
    AArch64 is pretty clean. I'd be surprised if their cores ran AArch32.
    - saagarjha 6y ago
      Apple’s? They don’t.
  - Jasper_ 6y ago
    RISC-V is basically a nonstarter. It has a lot of ridiculously goofy decisions in its ISA, it doesn't seem like competent CPU nor compiler engineers were ever in the loop for its design, and the number one benefit seems to be the licensing terms that make it super easy to extend or even replace 90% of the ISA while still calling it "RISC-V".
    - monocasa 6y ago
      Can you enumerate some of these goofy decisions?
      - Jasper_ 6y ago
        Sure. The most notable one I can think of is that integer multiplication is not in core. It's an extension. Anybody that's written a compiler or even stared at assembly would tell you how prevalent integer multiplication is, for any sort of loop or pointer addressing. Even more baffling, is that the same extension that adds integer multiplication, also requires integer division, telling me that the spec authors think that multiplication and division are of the same circuit complexity, and used with the same frequency. And for one example for how goofy of an idea that is, ARM has never included integer division in its core ISA. Then there's the whole JALR mess, which I don't know how to describe it other than "tech debt". Basically, they tried to simplify different kinds of jumps and returns into a single extension, by allowing any register to be used for the source and destination addresses. But for branch prediction reasons, and prefetching, you really do want to have a single link register, so the spec says "please don't use anything other than x1 as the link register, or you might not get proper performance". There's a lot more that I can go into.
        monocasa 6y ago
        > The most notable one I can think of is that integer multiplication is not in core. It's an extension. Anybody that's written a compiler or even stared at assembly would tell you how prevalent integer multiplication is, for any sort of loop or pointer addressing. Those use cases work just fine with the shifts and adds trick you can do for multiply by constant. Honestly I was always baffled that ARMv6-M required a multiplier. Seemed to be the closest thing to an albatross over it's head, so much so that there were those M0's with an iterative, 32 cycle latency, bit serial multiplier. > Even more baffling, is that the same extension that adds integer multiplication, also requires integer division, telling me that the spec authors think that multiplication and division are of the same circuit complexity, and used with the same frequency. And for one example for how goofy of an idea that is, ARM has never included integer division in its core ISA. ARMv7-M (the closest ISA to Rv32-EM) requires integer divide. > Then there's the whole JALR mess, which I don't know how to describe it other than "tech debt". Basically, they tried to simplify different kinds of jumps and returns into a single extension, by allowing any register to be used for the return address. But for branch prediction reasons, you really do want to have a single link register, so the spec says "please don't use anything other than x1 as the link register, or you might not get proper performance". I don't really see this as a problem. For instance it neatly encodes unconditional jump without link as a jump with link to x0. Reminds me of some of the cute ways to encodes jumps from SH without being quite as ascetic. > There's a lot more that I can go into. Please do. Like totally unironically. I obviously have a pretty high opinion of RISC-V, but I appreciate someone who helps keep my biases in check.
  - klelatti 6y ago
    Any ARM CPU that Apple uses in Macs will almost certainly be 64 bit A64 only - A64 is the only instruction set that has been supported on Apple SoC's since the A11 in 2017. A64 is part of ARMv8 which was announced in October 2011 and was a brand new instruction set. It is not compatible with legacy 32 bit ARM applications and doesn't carry the relevant technical debt. RISC-V was announced in 2010. It may have many admirable qualities but claiming that it has the advantage of a newer architecture is not correct in this context. Incidentally, I think one of the remarkable features of ARM's recent commercial success - generally completely unremarked on - is how they have, relatively seamlessly, switched users from legacy 32 bit to an new 64 instruction set.
- CyanLite2 6y ago
  Many of the technical innovations from Intel over the past 5-10 years have been rolled back due to security or regression issues. TSX, SMT, AVX-512 just to name a few.
  - throwaway2048 6y ago
    Again, that has nothing to do with the "technical debt" of x86 as an instruction set per se.
baybal2 6y ago
AMD is ARM architectural licensee. They already tried to slap ARM frontend to their cores for their cancelled ARM based opterons. Nothing prevents them slapping ARM frontend onto Zen

tenebrisalietum 6y ago

> And x86 CPUs still are required to support 16-bit devices from 35 years ago. I heard somewhere that this year Intel was going to begin to phase out support for BIOS, which would allow Intel to eliminate CPUs booting up in "real mode". I think as long as plain PCI is something supported, some sort of 16-bit support has to be in the firmware because of option ROMs. Though I'm not sure UEFI couldn't service those with some sort of emulation layer (may as well, UEFI's already complex enough).

throwaway2048 6y ago

Intel (and AMD's) problems have nothing to do with any supposed "technical debt" imposed by x86. Also, the x86 instruction set gets upgraded with practically every single generation of Intel and AMD processor.

bcatanzaro 6y ago
ARM is very old as well and has plenty of technical debt. RISCV, on the other hand...
- mikece 6y ago
  What do you suppose the chances are of Apple compiling/running iOS and macOC on RISCV?
  - pram 6y ago
    zero percent
  - dathinab 6y ago
    Closer to zero, it's an open architecture something the king of walled gardens wouldn't touch from a mile away. ;=) Jokes aside the real reason why it's extremely unlikely is that they put a lot of money into ARM and they simply have no reason to switch to it. For this to happen ARM would need to do something like massively increase the price of their IP licenses, or simila. Which won't happen.
  - monocasa 6y ago
    Apple has even a less incentive then most to support RISC-V versus ARM. They were a super early investor in ARM back in the early 90s (to the point where ARM probably wouldn't exist today without Apple). I'd be surprised if they pay more than a token amount for their core licenses. For all intents and purposes, RISC-V being open just puts it on the same footing for Apple as ARM is for them.
- monocasa 6y ago
  AArch64 is pretty clean. I'd be surprised if their cores ran AArch32.
  - saagarjha 6y ago
    Apple’s? They don’t.
- Jasper_ 6y ago
  RISC-V is basically a nonstarter. It has a lot of ridiculously goofy decisions in its ISA, it doesn't seem like competent CPU nor compiler engineers were ever in the loop for its design, and the number one benefit seems to be the licensing terms that make it super easy to extend or even replace 90% of the ISA while still calling it "RISC-V".
  - monocasa 6y ago
    Can you enumerate some of these goofy decisions?
    - Jasper_ 6y ago
      Sure. The most notable one I can think of is that integer multiplication is not in core. It's an extension. Anybody that's written a compiler or even stared at assembly would tell you how prevalent integer multiplication is, for any sort of loop or pointer addressing. Even more baffling, is that the same extension that adds integer multiplication, also requires integer division, telling me that the spec authors think that multiplication and division are of the same circuit complexity, and used with the same frequency. And for one example for how goofy of an idea that is, ARM has never included integer division in its core ISA. Then there's the whole JALR mess, which I don't know how to describe it other than "tech debt". Basically, they tried to simplify different kinds of jumps and returns into a single extension, by allowing any register to be used for the source and destination addresses. But for branch prediction reasons, and prefetching, you really do want to have a single link register, so the spec says "please don't use anything other than x1 as the link register, or you might not get proper performance". There's a lot more that I can go into.
      - monocasa 6y ago
        > The most notable one I can think of is that integer multiplication is not in core. It's an extension. Anybody that's written a compiler or even stared at assembly would tell you how prevalent integer multiplication is, for any sort of loop or pointer addressing. Those use cases work just fine with the shifts and adds trick you can do for multiply by constant. Honestly I was always baffled that ARMv6-M required a multiplier. Seemed to be the closest thing to an albatross over it's head, so much so that there were those M0's with an iterative, 32 cycle latency, bit serial multiplier. > Even more baffling, is that the same extension that adds integer multiplication, also requires integer division, telling me that the spec authors think that multiplication and division are of the same circuit complexity, and used with the same frequency. And for one example for how goofy of an idea that is, ARM has never included integer division in its core ISA. ARMv7-M (the closest ISA to Rv32-EM) requires integer divide. > Then there's the whole JALR mess, which I don't know how to describe it other than "tech debt". Basically, they tried to simplify different kinds of jumps and returns into a single extension, by allowing any register to be used for the return address. But for branch prediction reasons, you really do want to have a single link register, so the spec says "please don't use anything other than x1 as the link register, or you might not get proper performance". I don't really see this as a problem. For instance it neatly encodes unconditional jump without link as a jump with link to x0. Reminds me of some of the cute ways to encodes jumps from SH without being quite as ascetic. > There's a lot more that I can go into. Please do. Like totally unironically. I obviously have a pretty high opinion of RISC-V, but I appreciate someone who helps keep my biases in check.
- klelatti 6y ago
  Any ARM CPU that Apple uses in Macs will almost certainly be 64 bit A64 only - A64 is the only instruction set that has been supported on Apple SoC's since the A11 in 2017. A64 is part of ARMv8 which was announced in October 2011 and was a brand new instruction set. It is not compatible with legacy 32 bit ARM applications and doesn't carry the relevant technical debt. RISC-V was announced in 2010. It may have many admirable qualities but claiming that it has the advantage of a newer architecture is not correct in this context. Incidentally, I think one of the remarkable features of ARM's recent commercial success - generally completely unremarked on - is how they have, relatively seamlessly, switched users from legacy 32 bit to an new 64 instruction set.
CyanLite2 6y ago
Many of the technical innovations from Intel over the past 5-10 years have been rolled back due to security or regression issues. TSX, SMT, AVX-512 just to name a few.
- throwaway2048 6y ago
  Again, that has nothing to do with the "technical debt" of x86 as an instruction set per se.

baybal2 6y ago

AMD is ARM architectural licensee. They already tried to slap ARM frontend to their cores for their cancelled ARM based opterons. Nothing prevents them slapping ARM frontend onto Zen