4 ms·

> In fact, I actually think need to continue supporting the legacy x86 ISA was a massive advantage to Intel. I think this is a myth that Intel (or somebody els

> In fact, I actually think need to continue supporting the legacy x86 ISA was a massive advantage to Intel. I think this is a myth that Intel (or somebody else) has invented in an attempt to save face. Legacy x86 instructions could have been culled from the silicon and implemented in the software as emulation traps – this has been done elsewhere nearly since the first revised CPU design came out. Since CPU's have been getting faster and faster, and legacy instructions have been used less and less, the emulation overhead would have been negligible to the point that no one would even notice it.

xscott 1y ago
They tried this with Itanium and got beaten up constantly about how legacy performance was bad. Personally, I agree with you, but the market isn't rational. This paved the way for AMD to eat some of their lunch by making a "compatible" 64 bit ISA. Itanium could've been great for the kinds of workloads I was interested in at the time.
phire 1y ago
We aren't talking about legacy instructions. Those have all been culled and replaced by microcode (in fact, most of them were always microcode from the very first 8086, they just never got non-microcoded versions thought the 286, 386, 486, pentium era). We are talking about how the whole ISA is legacy. How the basic structure of the encoding is complex and hard to decode. How the newer instructions get longer encodings. Or things which can be done with a single instruction on some RISC ISAs take 3 or 4 instructions.
- inkyoto 1y ago
  I was actually commenting on the need to support aspect being a myth. x86 is not a legacy, it is a legacy of legacies as the x86 ISA ascends all the way to 8008 via 8080 at least as a spiritual predecessor even if it can't directly execute the 8008 binary code. Intel also had their own, indigeneous, RISC design – i960, which was a very good RISC design. At some point – if I am not mistaken – Intel contemplated phasing out the x86 ISA and replacing it with i960, but there was a change of plans, and they went all in with the 80486 CPU. i960 remained around in embedded and defence applications. Intel also had their own hybrid VLIW/RISC design, i860, which preceded Itanium, and which they did not know what to do. Similarly, they faced the same issue with compilers of the day not being to produce fast code.
  - phire 1y ago
    > if I am not mistaken – Intel contemplated phasing out the x86 ISA and replacing it with i960, but there was a change of plans, I don't think there was ever any serious thought about replacing x86 with i960 (at least nothing publicly). There was a serious plan to replace x86 with the iAPX 432, which is the predecessor to the i960, but those plans all predated x86 becoming a run-away success when the IBM PC became an industry standard. And "replace" is kind of over stating it, there was no plan for any compatibility, not even source compatibility. It's more that they were planning for iAPX 432 to take the "workstation CPU" spot on their product chart that was currently occupied by the 8086. By the time the i960 was in development, x86 was so entrenched that I really doubt there could have been any serious thoughts of replacing x86 with something that wasn't fully backwards compatible. And we know that when Intel did try to replace x86 with Itanium, they went with a hardware backwards compatibility mode. > I was actually commenting on the need to support aspect being a myth. Yes, you have a point that it should have been possible to replace x86 with a software emulation approach. But the only person who can really do that is the platform owner. Apple were quite successful with their 68k to PowerPC transition. And the PowerPC to x86 transition. And the x86 to Aarch64 transition. But that transition really needs to be done by the platform owner. But the PC didn't really have an owner. IBM had lost control of it. You could argue that Microsoft had control, but they didn't have enough control (especially with DOS. Most DOS programs were bypassing DOS to some extent or another and directly accessed hardware). Intel certainly didn't have enough control to transition to another arch. (The PC had such high demands for backwards compatibility that even the Pentium Pro ran into issue. It worked, but it simply wasn't fast enough when executing instructions with 16-bit operands. Attempting to run DOS or win95 apps would be slower than a 486. So the Pentium Pro was limited to the market of Windows NT workstations running Apps with full 32-bit code. Intel had to fix this with the Pentium II before they could sell the P6 arch outside of the workstation market.) Intel didn't even have control over x86 itself. Other companies were already making competing CPU designs that were faster than Intel's own. If Intel didn't keep releasing faster x86 designs, then someone else would steal all of their market share. Intel were more or less forced to keep releasing faster native x86 designs, or they would lose what little control they did have.
    - 1y ago

xscott 1y ago

They tried this with Itanium and got beaten up constantly about how legacy performance was bad. Personally, I agree with you, but the market isn't rational. This paved the way for AMD to eat some of their lunch by making a "compatible" 64 bit ISA. Itanium could've been great for the kinds of workloads I was interested in at the time.

phire 1y ago

We aren't talking about legacy instructions. Those have all been culled and replaced by microcode (in fact, most of them were always microcode from the very first 8086, they just never got non-microcoded versions thought the 286, 386, 486, pentium era). We are talking about how the whole ISA is legacy. How the basic structure of the encoding is complex and hard to decode. How the newer instructions get longer encodings. Or things which can be done with a single instruction on some RISC ISAs take 3 or 4 instructions.

inkyoto 1y ago
I was actually commenting on the need to support aspect being a myth. x86 is not a legacy, it is a legacy of legacies as the x86 ISA ascends all the way to 8008 via 8080 at least as a spiritual predecessor even if it can't directly execute the 8008 binary code. Intel also had their own, indigeneous, RISC design – i960, which was a very good RISC design. At some point – if I am not mistaken – Intel contemplated phasing out the x86 ISA and replacing it with i960, but there was a change of plans, and they went all in with the 80486 CPU. i960 remained around in embedded and defence applications. Intel also had their own hybrid VLIW/RISC design, i860, which preceded Itanium, and which they did not know what to do. Similarly, they faced the same issue with compilers of the day not being to produce fast code.
- phire 1y ago
  > if I am not mistaken – Intel contemplated phasing out the x86 ISA and replacing it with i960, but there was a change of plans, I don't think there was ever any serious thought about replacing x86 with i960 (at least nothing publicly). There was a serious plan to replace x86 with the iAPX 432, which is the predecessor to the i960, but those plans all predated x86 becoming a run-away success when the IBM PC became an industry standard. And "replace" is kind of over stating it, there was no plan for any compatibility, not even source compatibility. It's more that they were planning for iAPX 432 to take the "workstation CPU" spot on their product chart that was currently occupied by the 8086. By the time the i960 was in development, x86 was so entrenched that I really doubt there could have been any serious thoughts of replacing x86 with something that wasn't fully backwards compatible. And we know that when Intel did try to replace x86 with Itanium, they went with a hardware backwards compatibility mode. > I was actually commenting on the need to support aspect being a myth. Yes, you have a point that it should have been possible to replace x86 with a software emulation approach. But the only person who can really do that is the platform owner. Apple were quite successful with their 68k to PowerPC transition. And the PowerPC to x86 transition. And the x86 to Aarch64 transition. But that transition really needs to be done by the platform owner. But the PC didn't really have an owner. IBM had lost control of it. You could argue that Microsoft had control, but they didn't have enough control (especially with DOS. Most DOS programs were bypassing DOS to some extent or another and directly accessed hardware). Intel certainly didn't have enough control to transition to another arch. (The PC had such high demands for backwards compatibility that even the Pentium Pro ran into issue. It worked, but it simply wasn't fast enough when executing instructions with 16-bit operands. Attempting to run DOS or win95 apps would be slower than a 486. So the Pentium Pro was limited to the market of Windows NT workstations running Apps with full 32-bit code. Intel had to fix this with the Pentium II before they could sell the P6 arch outside of the workstation market.) Intel didn't even have control over x86 itself. Other companies were already making competing CPU designs that were faster than Intel's own. If Intel didn't keep releasing faster x86 designs, then someone else would steal all of their market share. Intel were more or less forced to keep releasing faster native x86 designs, or they would lose what little control they did have.
  - 1y ago