6 ms·

> even more of a kludge than the Apple IIgs (a 16-bit computer built around an 8-bit one from the previous decade) Well, on the other hand, it did give us the

> even more of a kludge than the Apple IIgs (a 16-bit computer built around an 8-bit one from the previous decade) Well, on the other hand, it did give us the 65816, which the SNES was built on top of. On the other other hand, though, it probably would have been better if the SNES had gone with m68k.

rbanffy 4y ago
The 65816 was as much a dead end as the 8086. Unfortunately, Apple saw that and discontinued the GS. IBM, unfortunately, doubled down with the 286, then 386 and here we are. Notably, IBM had a 68000 desktop computer that ran Xenix, the IBM CS 9000. https://archive.org/details/byte-magazine-1984-02/page/n279/mode/1up https://archive.org/details/byte-magazine-1984-02/page/n279/...
- ajross 4y ago
  > The 65816 was as much a dead end as the 8086. The 8086 was a... what now?
  - rbanffy 4y ago
    It's a horrible architecture. Every iteration on top of it made it even more hideous. It's a unnatural thing that should have never been. Every time an x86 powers up, it cries in despair and begs to be killed.
    - jabl 4y ago
      Meh. Just hold your nose when the processor boots until it gets into protected or long mode and you're good to go. If ARM or RISC-V eventually take over the x86 market, it will be due to business model reasons and not the superiority of the ISA.
      - snvzz 4y ago
        Reasoning for the take-over aside, they're still superior ISAs. If it is RISC-V, I will celebrate it.
    - tssva 4y ago
      > unfortunately, doubled down with the 286, then 386 and here we are. It may be a horrible architecture but the fact that we are here is a pretty good testament to it not being a dead end.
    - pcwalton 4y ago
      It's funny to see this sentiment wax and wane with Intel's market fortunes. In the early 2010s on this site, with Intel riding high, you'd see lots of comments talking about how x86 was just months away from killing ARM for good on account of a better technical design. Now it's the reverse: people are treating x86 as a horrible dinosaur of an architecture that's on its last legs. Personally, I think x86 is pretty ugly, but both compilers and chip designers have done an admirable job taming it, so it's not that bad. Process/fabrication concerns tend to dominate nowadays.
    - robocat 4y ago
      Your complaint is the designer’s lament, regrets because fast iterations will usually beat a cohesive development, the struggle to accept that the imperfect delivered today wins versus the perfect delivered tomorrow. A good engineer chooses their battles, fights for the right compromises, and grudgingly accepts that the evolutionary remnants in all our engineering artefacts are the price we pay for the results of iterative path dependency. For example, Intel didn’t design the x64 ISA. Practice beats perfection The engineer’s game we play Make do with what we've got And make it work today If you watch Jim Keller talk about microprocessor design, he seems to say that designs converge due to real world constraints and factors. Human designers are imperfect, which Jim seems to be very good at acknowledging. Every now and then we get to refactor, and remove some limiting kludge. But the number of kludges increases with complexity, and kludges are the result of compromises forced by externalities, so the nirvana of a kludge-free world can only be reached in engineer’s fairy tales. Disclaimer: I was an engineer type, but turned dark by the desire for the fruits of capitalism. (Edited)
    - skissane 4y ago
      > Every time an x86 powers up, it cries in despair and begs to be killed. Intel/AMD could make their new CPUs start in protected mode, even long mode - and nowadays, likely nobody other than BIOS developers would ever notice. Why don’t they? I guess it would be a fair amount of work with no clear benefit. One thing they could do - legacy features (real mode, 16-bit protected mode, V86 mode, etc) are now an optional feature for which you have to pay a premium. They could just have a mode which disables them, and fuse that mode on in the factory. With Microsoft’s cooperation, Windows 11 could be made to run on such a CPU without much work. Likely few would demand the optional feature, and it would soon disappear
      - pcwalton 4y ago
        > One thing they could do - legacy features (real mode, 16-bit protected mode, V86 mode, etc) are now an optional feature for which you have to pay a premium. They could just have a mode which disables them, and fuse that mode on in the factory. With Microsoft’s cooperation, Windows 11 could be made to run on such a CPU without much work. Customers who need them could just emulate them. Almost everyone already does anyway (DOSBox, etc.) Though, honestly, I highly suspect the die space spent to support those features is pretty small, and power dissipation concerns mean that it's quite possible there aren't much better uses for that silicon area.
        skissane 4y ago
        It inevitably has a cost though, even if at design-time than runtime. Consider a code base filled with numerous legacy features which almost nobody ever uses. Their presence in the code and documentation means it takes longer for people to understand. Adding new features takes more time, because you have to consider how they interact with the legacy ones, and the risk of introducing regressions or security vulnerabilities through those obscure interactions. You need tests for all these legacy features, which makes testing take more time and be more expensive, and people working on newer features break the legacy tests and have to deal with that. Technical debt has a real cost - and why would that be any less true for a CPU defined in Verilog/VHDL than for a programming language? And a feature flag is a good way to get rid of legacy features. First add the flag but leave it on. Then start turning it off by default but let people turn it back on for free. Then start charging people money to have it on. Then remove it entirely, and all the legacy features it gates. It works for software-I can’t see why it couldn’t work for hardware too.
ajross 4y ago
The 65C816 is another device that I think gets too much play. It's a relatively straightforward extension of an 8 bit idea to 16 bits, with a few (but just a few) more registers and some address stretching trickery to get more than 64k of (fairly) easily addressible RAM. Which is to say, the 65C816 did pretty much exactly what the 8086 had done, including a bunch of the same mistakes[1]. Which would have been fine if these were head-to-head competitors. But the 8086 shipped six years earlier! [1] Though not quite 1:1. Intel had a 16 bit data bus from the start, but the WDC segmentation model was cleaner, etc...
- mikepavone 4y ago
  > but the WDC segmentation model was cleaner, etc... Eh, I don't think this is generally true. Intel's decision to have the segments overlap so much was definitely very short-sighted, but the 8086 has a big advantage in having multiple segment registers with the ability to override which is used via an instruction prefix. This makes copying data between two pages straightforward on the 8086 whereas you need to constantly reload the databank register on the 65C816. I think as a pure 16-bit design the 8086 is actually pretty good. It's not at all a forward-looking design though so it wasn't well suited to being the basis of the default PC architecture for decades to come.
  - pcwalton 4y ago
    > This makes copying data between two pages straightforward on the 8086 whereas you need to constantly reload the databank register on the 65C816. Don't the MVN and MVP block transfer instructions let you specify separate data banks for the source and the destination? (I agree that the 8086 was a superior design to the 65816 in most other ways.)
    - mikepavone 4y ago
      You're right. If all you want to do is literally copy bytes without any other processing then those instructions will handle it.
- renewedrebecca 4y ago

rbanffy 4y ago

The 65816 was as much a dead end as the 8086. Unfortunately, Apple saw that and discontinued the GS. IBM, unfortunately, doubled down with the 286, then 386 and here we are. Notably, IBM had a 68000 desktop computer that ran Xenix, the IBM CS 9000. https://archive.org/details/byte-magazine-1984-02/page/n279/mode/1up https://archive.org/details/byte-magazine-1984-02/page/n279/...

ajross 4y ago
> The 65816 was as much a dead end as the 8086. The 8086 was a... what now?
- rbanffy 4y ago
  It's a horrible architecture. Every iteration on top of it made it even more hideous. It's a unnatural thing that should have never been. Every time an x86 powers up, it cries in despair and begs to be killed.
  - jabl 4y ago
    Meh. Just hold your nose when the processor boots until it gets into protected or long mode and you're good to go. If ARM or RISC-V eventually take over the x86 market, it will be due to business model reasons and not the superiority of the ISA.
    - snvzz 4y ago
      Reasoning for the take-over aside, they're still superior ISAs. If it is RISC-V, I will celebrate it.
  - tssva 4y ago
    > unfortunately, doubled down with the 286, then 386 and here we are. It may be a horrible architecture but the fact that we are here is a pretty good testament to it not being a dead end.
  - pcwalton 4y ago
    It's funny to see this sentiment wax and wane with Intel's market fortunes. In the early 2010s on this site, with Intel riding high, you'd see lots of comments talking about how x86 was just months away from killing ARM for good on account of a better technical design. Now it's the reverse: people are treating x86 as a horrible dinosaur of an architecture that's on its last legs. Personally, I think x86 is pretty ugly, but both compilers and chip designers have done an admirable job taming it, so it's not that bad. Process/fabrication concerns tend to dominate nowadays.
  - robocat 4y ago
    Your complaint is the designer’s lament, regrets because fast iterations will usually beat a cohesive development, the struggle to accept that the imperfect delivered today wins versus the perfect delivered tomorrow. A good engineer chooses their battles, fights for the right compromises, and grudgingly accepts that the evolutionary remnants in all our engineering artefacts are the price we pay for the results of iterative path dependency. For example, Intel didn’t design the x64 ISA. Practice beats perfection The engineer’s game we play Make do with what we've got And make it work today If you watch Jim Keller talk about microprocessor design, he seems to say that designs converge due to real world constraints and factors. Human designers are imperfect, which Jim seems to be very good at acknowledging. Every now and then we get to refactor, and remove some limiting kludge. But the number of kludges increases with complexity, and kludges are the result of compromises forced by externalities, so the nirvana of a kludge-free world can only be reached in engineer’s fairy tales. Disclaimer: I was an engineer type, but turned dark by the desire for the fruits of capitalism. (Edited)
  - skissane 4y ago
    > Every time an x86 powers up, it cries in despair and begs to be killed. Intel/AMD could make their new CPUs start in protected mode, even long mode - and nowadays, likely nobody other than BIOS developers would ever notice. Why don’t they? I guess it would be a fair amount of work with no clear benefit. One thing they could do - legacy features (real mode, 16-bit protected mode, V86 mode, etc) are now an optional feature for which you have to pay a premium. They could just have a mode which disables them, and fuse that mode on in the factory. With Microsoft’s cooperation, Windows 11 could be made to run on such a CPU without much work. Likely few would demand the optional feature, and it would soon disappear
    - pcwalton 4y ago
      > One thing they could do - legacy features (real mode, 16-bit protected mode, V86 mode, etc) are now an optional feature for which you have to pay a premium. They could just have a mode which disables them, and fuse that mode on in the factory. With Microsoft’s cooperation, Windows 11 could be made to run on such a CPU without much work. Customers who need them could just emulate them. Almost everyone already does anyway (DOSBox, etc.) Though, honestly, I highly suspect the die space spent to support those features is pretty small, and power dissipation concerns mean that it's quite possible there aren't much better uses for that silicon area.
      - skissane 4y ago
        It inevitably has a cost though, even if at design-time than runtime. Consider a code base filled with numerous legacy features which almost nobody ever uses. Their presence in the code and documentation means it takes longer for people to understand. Adding new features takes more time, because you have to consider how they interact with the legacy ones, and the risk of introducing regressions or security vulnerabilities through those obscure interactions. You need tests for all these legacy features, which makes testing take more time and be more expensive, and people working on newer features break the legacy tests and have to deal with that. Technical debt has a real cost - and why would that be any less true for a CPU defined in Verilog/VHDL than for a programming language? And a feature flag is a good way to get rid of legacy features. First add the flag but leave it on. Then start turning it off by default but let people turn it back on for free. Then start charging people money to have it on. Then remove it entirely, and all the legacy features it gates. It works for software-I can’t see why it couldn’t work for hardware too.

ajross 4y ago

The 65C816 is another device that I think gets too much play. It's a relatively straightforward extension of an 8 bit idea to 16 bits, with a few (but just a few) more registers and some address stretching trickery to get more than 64k of (fairly) easily addressible RAM. Which is to say, the 65C816 did pretty much exactly what the 8086 had done, including a bunch of the same mistakes[1]. Which would have been fine if these were head-to-head competitors. But the 8086 shipped six years earlier! [1] Though not quite 1:1. Intel had a 16 bit data bus from the start, but the WDC segmentation model was cleaner, etc...

mikepavone 4y ago
> but the WDC segmentation model was cleaner, etc... Eh, I don't think this is generally true. Intel's decision to have the segments overlap so much was definitely very short-sighted, but the 8086 has a big advantage in having multiple segment registers with the ability to override which is used via an instruction prefix. This makes copying data between two pages straightforward on the 8086 whereas you need to constantly reload the databank register on the 65C816. I think as a pure 16-bit design the 8086 is actually pretty good. It's not at all a forward-looking design though so it wasn't well suited to being the basis of the default PC architecture for decades to come.
- pcwalton 4y ago
  > This makes copying data between two pages straightforward on the 8086 whereas you need to constantly reload the databank register on the 65C816. Don't the MVN and MVP block transfer instructions let you specify separate data banks for the source and the destination? (I agree that the 8086 was a superior design to the 65816 in most other ways.)
  - mikepavone 4y ago
    You're right. If all you want to do is literally copy bytes without any other processing then those instructions will handle it.
renewedrebecca 4y ago