James_Parsons wrote:
I would probably add more general purpose registers
Well, more is usually better. But you should consider that microprocessors from the 70s had limited silicon space, and trade-offs were almost always at the fore-front for the design teams. The 6502 team appeared to have a certain philosophy in mind when they made it with a single accumulator and stack pointer, and two index registers. It's addressing modes seemed rather contrived to some of the newcomers of the time, but it quickly became apparent that they were incredibly useful when pushed to their true potential. When I try to think about improving something, I think about how to make it more efficient without changing its basic look and feel too much. How much is too much is a matter of opinion, but I think that replacing the single accumulator with a general-purpose register bank crosses the line, and doesn't just improve the 6502, but makes it something that feels completely different.
Its older step-brother, the 6800, had wider pointer registers and two accumulators, but certain things that happen all the time, like moving an arbitrary range of memory from one spot to another, are inefficient because its indexing address mode is crippled by a hard-coded 8-bit offset and a missing Y register. Most 6800 programmers lived with the inefficiencies, or employed unsafe tricks with the system stack pointer. The X register was 16-bits, which is nice, but CPX only correctly recognized equality, and the code to save and restore X to/from the system stack was clumsy and inefficient. Other qualities that annoy me are the way that it clears carry when you load an accumulator, and the way that it requires you to TST an accumulator that you have just pulled. It does okay on cycle counts, but cannot match the more efficient little-endian and pipe-lined 6502. The 6809 addressed many (but not all) of these issues, and is quite a capable little unit IMO, discounting the 'tacked-on' nature of some of its features. I respect the 6800/6809, but don't consider myself to be a true fan of either.
Its stiffest competition, the Z-80, had more (and wider) registers and a much richer instruction set, but it was hampered by inefficient memory accesses and some legacy issues with the old 8080 instruction set. I cannot speak from first-hand experience, but I have read that some of the neat-looking features are not-so-neat when actually put to work. The use of the index registers bloated and slowed the code, and many of the addressing modes were not available at the right moment. The way that it updates (or doesn't update) the condition flags are different than the 6800, but just as irksome to me. Many of the improvements from the 8080 to the Z-80 had a "tacked-on" feel as well. Although I think that it has a few neat (and unique) features, I do not consider myself to be a fan of the Z-80.
What it boils down to IMO is not how impressive it looks on paper, but how it can be efficiently employed to do something useful. There are a lot of expert 8080 and Z-80 programmers out there that can make their processor dance beautifully, but it takes a lot of experience to do it quickly and efficiently. Something non-trivial, like a BASIC interpreter, can be full of inefficiencies and compromises. The 6502 versions of the same BASIC interpreters came a bit later than those of the 6800 and 8080, but were not translated directly from the 6800 or 8080; they were re-written from scratch to do the same thing, but by someone who clearly knew how to make the 6502 dance. At the hands of a true artist, any of these little machines can be made to do impressive things, but most of us here believe that, at its very best, even with its little quirks and limitations, the 6502 actually WAS the best, all things considered. And many performance bench-marks support this belief.
Okay, back to my original point. My attempt to improve on it starts out as another case of how it looks on paper. With all of the available op-code space, I could have included hundreds of registers, but it wouldn't have had that accumulator-centric look and feel that many of us here have grown to know and love. To help me get away from the static specs and decide how useful it is, I have attempted to rewrite code written for the 6502, to see how natural, easy, and efficient it turns out to be. Whether or not it could be done cheaply and efficiently in actual silicon is another matter, one which I am unfortunately not qualified to address at this time.
Take care,
Mike
_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some
VTL02C on it and see how it grows on you!
Mike B.
(about me) (learning how to github)
Login
Register
FAQ
Search
It needs to be replaced with:
That's partly what I'm after! 2do has 1/10th as many instructions. Hopefully it would be fewer clocks per instruction too, making it conceivably maybe 20 times as fast at a given clock speed. If it could run at even 20MHz, that would allow normal memory and off-the-shelf I/O ICs and still be several times as fast as a 100MHz FPGA 65c02 when constantly having to deal with the wider numbers. The names won't need the "2" as in "2do" to get 32 bits with the 65m32 though, as it's naturally 32-bit anyway. 2+loop, the internal compiled by 2+LOOP, has 59 instructions by my count. It would be fun to see what that comes down to.
)