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...
The only new registers are the code bank and data bank registers, and I think the code bank register can't even be directly set. You have to do a 24-bit JMP or JSR, and that automatically changes the bank.
The A/X/Y registers all get extended to 16-bits, but A can be addressed as 'A' and 'B', two 8-bit registers. A mode change is necessary for this.
It's a particularly hard CPU to generate code for. There's a commercial, free to use for private use C compiler, but most people use assembler.
Pointers are a pain in the butt... You have to use a direct page memory location to fake a 24-bit pointer. On the 8086, you could at least use the ES register to point anywhere without a DP access.
I had forgotten about that! Yeah, that's horrendous.
> The only new registers are the code bank and data bank registers
There's the relocatable DP register, which you could use as a frame pointer (I've written code that does this). It's still quite awkward though.
> I think the code bank register can't even be directly set. You have to do a 24-bit JMP or JSR, and that automatically changes the bank.
To be fair that's how x86 works too, right? You have to do a far jump or far call to switch CS. (Also you could push addresses on the stack and do a far return on both 65816 and x86.)
> It's a particularly hard CPU to generate code for. There's a commercial, free to use for private use C compiler, but most people use assembler.
This is absolutely true. 6502 derivatives are almost uniquely hostile to C-like languages—witness all the failed attempts at porting LLVM to them—and the 65816 is no exception. I'm pretty sure that in an alternate world where 6502-based microcomputers had become dominant, the classic 6502 ISA would have quickly become relegated to some sort of legacy emulation mode, and the "normal" ISA would be nothing like it, unlike the relatively modest extensions that the 286 and 386 made to the 8086 ISA.
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.
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.)
Notably, IBM had a 68000 desktop computer that ran Xenix, the IBM CS 9000.
https://archive.org/details/byte-magazine-1984-02/page/n279/...
The 8086 was a... what now?
Practice beats perfection
The engineer’s game we play
Make do with what we've got
And make it work today
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.
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
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.
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.
If they really are such a security risk, surely enterprise customers would rather pay for the ability to turn them off.
There must be dies being thrown away right now because they work perfectly except for one of these legacy features. If they had SKUs with legacy features fused off, suddenly those dies might become usable.
Having lower-end SKUs with some features fused off allows you to use dies in which those features are broken. But, it means you have to fuse them off even on the dies in which they work. Buying a low end CPU and finding that some of them randomly have higher-end features would just be too confusing for everyone.
Fundamentally changing the instruction format might save a little bit of space, but then it wouldn't be compatible with x86-64 anymore either.
You may well be right, that a die being damaged in exactly that way, is rare enough, that the additional yield from being able to use such dies is rather marginal. But I think it would be hard for anyone to know for sure without non-public info.
> Fundamentally changing the instruction format might save a little bit of space, but then it wouldn't be compatible with x86-64 anymore either.
I wasn't talking about that. A CPU which didn't support real mode, 16-bit segments, etc, would still have the same instruction format, so instruction decode would be largely unchanged.
I wonder if we'll ever see a CPU which supports executing both x86 and ARM code, through separate instruction decoders but with a shared execution engine. Of course, there are lots of differences between the two architectures beyond just the instruction decoding, yet in some ways those differences are shrinking (when you look at features like Apple Silicon TSO mode, and Windows 11 ARM64EC architecture).
If it is RISC-V, I will celebrate it.
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.
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.