Over in
another topic, discussion has ensued concerning a member's
"dislike" of the 65C816. To wit:
Much of what I dislike about the 65816 stems from the different design choices they made compared to the 68000. Here is a brief list:
- 8-bit data bus (vs. 16-bits for 68000)
- Small register file and lack of general purpose registers
- Segmented memory architecture (ala x86)
- Lack of prioritized interrupts
However, I'm sure you're right that there are some good things about it that I may not be aware of not having used it much. For one, I believe it's more efficient than the 68000 in terms of clock cycles, though back in the day you couldn't get a 65816 that could be clocked nearly as fast as a 68000. And I suppose that as an experienced 6502 programmer, it may feel somewhat natural to transition to from the 6502.
A key statement in the above is
However, I'm sure you're right that there are some good things about it that I may not be aware of not having used it much. Having read this, a childhood experience immediately comes to mind, a time when broccoli was served with dinner:
"I don't like broccoli. It's yucky!"
"How do you know that it's yucky if you haven't eaten it?"
How would one know to like or dislike a microprocessor if one, by one's own admission, has not had any experience with it?
Now, it's not my intention to shame, cajole or otherwise exhort anyone to design their next computing device around a 65C816—notwithstanding the fact that this is a 6502 forum and the 65C816 is the most advanced and powerful member of the 6502 family. If the Motorola 68K suits one's needs then by all means use it. If one thinks that a Zilog Z80 is the next best thing since sliced bread that's fine as well. If you're into making your microprocessor from a pile of 74-series gates, flops, ALUs, etc.,
a la the Big Mess O' Wires project, fantastic!
All microprocessors embody design compromises and tradeoffs. In the case of the 65C816, the compromises and tradeoffs had to do with the desire to make it as bus- and software-compatible as possible with other 65xx hardware. The impetus for doing so came directly from Apple Computer—indeed, it could be said that had Apple not developed the under-appreciated IIgs with the ability to run older Apple II software the 65C816 may well have never been born. Hence the 65C816 is the way it is because of the desire to maintain backward compatibility with the 65C02 and predecessors (just as current x86 MPUs carry around 8088 baggage).
As the 65C816 is a compatible form of the 6502, it carries many of the strengths and weaknesses of the 6502. It also introduces capabilities that simply do not exist in the 6502 or 65C02. More capabilities mean there are more aspects to programming the 65C816, such as setting register sizes, relocating the stack, dealing with more interrupt sources, etc. However, considering those aspects in software design is optional, not mandatory. My first iteration of POC ran the 65C816 in emulation mode as I debugged the hardware. Even after permanently switching it to native mode, I continued for a while using the emulation mode software,
which worked without changing any code other than hardware vectors.
Relative to other contemporary microprocessor designs, e.g., the aforementioned 68K, the 65C816's performance when measured in terms of throughput at any given clock rate is comparable and in some cases, better. The 68K, for example, has a complicated interrupt response behavior and thus suffers from significant interrupt latency. My experiences with the 68K-powered minicomputers that dominated much of the 1980s bears that out: they all had lackluster I/O performance, an area where interrupts play a big role. On the other hand, the 68K's surfeit of general purpose registers and generally orthogonal programming model makes it quite efficient at compute-bound tasks. However, at identical clock speeds, the 65C816 will often outperform the 68K in that area unless heavy duty math is involved (no multiply and divide instructions in the 65C816).
I have assembly language programming experience with the 68K, as well as with the 6502 family. However, I prefer the latter, as its assembly language seems to be more conducive to the visualization and solution of problems. So while I don't think the 68K "tastes yucky," I don't think it is as flavorful as the 65C816.