You are right. There is no standard system in the 65xx world.

The concept discussed here is related to the resources that would be available to the assembler programmer of any system, though. Again: what about having two or more accumulators in the CPU instead of one?





Thanks for those interesting links

Doesn't the 6809 have 2 accumulators? The '816 allows you to swap 2 x 8-bit accumulators...

But other than that, what you're written is very much like the first sentence in many RISC ISAs...

The RISC systems I've used (Sparc, i860, RISC-V) don't have accumulators as such, but have a bank of registers that all work the same - you can add any register to any register and put the result in any register, or use any register as a pointer to memory to load/store any other register (sometimes optionally adding on another register as an indirection in the process), and so on.

Some might suggest that after their 6502 and 65816 computers, Acorn developed the ARM as a successor to those CPUs... 32 x 32bit registers and while the amount of ARM code I've written is less than a folded page of A4 it seems to be fairly orthogonal...

But once you have many registers it's then up to a combination of you, the user to use those registers but beware mixing use if you pull in some pre-compiled libraries that expect certain registers to behave in various ways (e.g. arguments to a called function, and so on)

I wrote an application recently in RISC-V assembler completely outside the suggested register use (for a compiler) and managed to fit the entire state of my system inside all those 31 registers - including an interrupt routine.... So it's possible to invent your own scheme if needed - you just have to write the whole system yourself. (My thing is a bytecode interpreter and it's blindingly fast on that architecture compared to the '816 I ported it from)

Maybe in the 6502 world look at Acheron?

https://github.com/AcheronVM/acheronvm

It's essentially macros that provide a 16-bit VM environment with multiple registers without the overhead of (say) a traditional bytecode VM...

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

FWIW, some folks believe the 6502 was originally planned to have two accumulators, and the opcode map does perhap lend plausiblility to the theory. If anyone's interested, there's more about that in this thread.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Considering most of the 6502 team had been involved in the two accumulator 6800, and the observations in that thread you linked to, it seems likely enough. A hypothetical two accumulator 6502 would have been a bit like an 8 bit version of the early 16-bit Data General Nova systems, which had two accumulators and two index registers (though no stack pointer). Something resembling the Data General Nova architecture wouldn't have been an odd choice to design towards - the microprogrammed Xerox Alto emulated its instruction set, at least in early releases.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

It's easy to do speed compares, but the reasons are fairly well understood - as I understand it, anyway -in that it boils down to clock usage efficiency - the 6502 can process a one byte instruction in 2 cycles (and the 2nd cycle is then reading the next instruction) where the Z80 needs more - a minimum of 4 and often many more.... then it starts over again, ah, new clock cycle, lets read the next instruction in rather than the one cycle overlap the 6502 can achieve. I think this is due to the effective use of both edges of the clock in the 6502 and what is effectively a single stage pipeline. I think early versions of other (wider) CPUs were similar - operations spread out over many clock cycles - possibly to try to keep things simple for early silicon technology and possibly even to keep things understandable for the people designing it as the chips got larger and larger.. RAM was still expensive, so early 68K systems could still work on an 8-bit wide memory system which doubles the clocks needed just to read in a 16-bit word, or double again for a 32-bit word. It really wasn't long before the 68K was featured in high-end Unix workstations and so on, Apollo, Sun and so on. (The early 80's was also a time of fierce competition - if your CPU didn't perform it wouldn't be bought and people weren't interested in waiting for the next revision)

RISC changed that - maybe not as much as expected, but the much touted one instruction per cycle was the goal - and it worked - until the CPU core got so much faster than the memory systems - a problem we still have today, and we see it even in our 6502 systems where we only have just under half a clock cycle to read or write RAM. RISC initially seemed slower as there were effectively less instructions so you had to write more lines of code to do the same thing but wider memory and caches kept the balance - at least for a while and you were dealing with wider data from the start. The advantage RISC (notably ARM) had for a very long time, and even today is low power - mostly due to a relatively low gate count, although when you start to add in vector capable FPUs and GPUs that starts to fall by the wayside.

I was part of "the 6502 is better than the Z80" brigade way back in the late 70's and early 80's, but it was relatively easy to fall into that slot - even though the Z80 CP/M systems I was using did seem much more capable - or at least they were good enough - for easier access to high level languages (Editors, Wordstar, Pascal and C) Possibly the difference between something looking more "operating system" like (after exposure to various mini computer OS's, Unix, etc.) so ultimate speed then wasn't really an issue, but applications were - the home computer users cared more for their games, etc. Or so it seemed, so ultimate speed and coding tricks ruled the day.

-G

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I'd put it slightly differently, but perhaps to similar effect: the 6800 and 6502 are unusual in having one machine cycle for each memory cycle. I think the 8-flavours from Intel and Zilog, and Moto's 68k, and National's 32k, all are designed to have several machine cycles per memory cycle. It's yet another set of engineering tradeoffs, which can only be understood by considering both choices.

Later micros with caches start to shift the tradeoffs.

I do wonder if people who start by learning to program a register-rich machine have more trouble adjusting to the 6502 type of machine, compared to those who start at the 6502 end of the spectrum. In much the same way, perhaps, as people who start by understanding C's use of the stack for parameters and local variable can struggle to understand the different idioms used in 6502 land.

Very good points.

In the assembly language world, I started on 6502, then Prime (horrible "mini" computer thing) then 8080. I took to the 8080 with relative ease and performance wasn't an issue (it was a real-time blood analysis machine where the process times were counted in 10's of milliseconds), but after that after a very brief dabble with ARM it was Transputer which has quite a unique architecture, then back into the RISC world with Sparc with it's plethora of registers and register windowing system and i860 with it's dual-instruction mode braincell destroying nightmare. I gave up on assembler after that and vowed to never look back since C was good enough, however that didn't quite work and I drifted back oddly enough into the PDP-8 world which didn't feel at all bad now that I recall...

In recent times I've been looking at RISC-V - and I recently ported my BCPL Cintcode VM from the '816 to it - the Cintcode registers which were in zero/direct page on the '816 mapped directly to real registers in the RV CPU and I was able to use other registers to good effect and essentially everything that was in Zero/Direct page in now in registers - so there is a parallel there between using pseudo 16/32 bit pointers/registers on the '816 to using real 32-bit registers in the RV.

But, as Ed says, engineering tradeoffs and challenges - both in the hardware and grey-cell worlds. Tools were evolving quickly in the late 70's and early 80's so it was easier to get the computer to do more work to improve layout, help save a cycle here and there, and so on.

Also markets - the 68K did do well - in commercial worlds - I think the N32K might have worked too, but they seemed to be plagued by initial production issues and bugs before it ended up in the "too little, too late" category. Or maybe it was just the home/hobby world that made most noise back then? It's just too easy to complain about speeds and discount other features - such as potentially faster arithmetic, bigger memory potentials and so on....

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

This is factually true but easy to misinterpret. In an apples-to-apples comparison you'd begin by establishing a level playing field with respect to memory speed (which dominates system cost). And the faster-clocked Z80 is quite happy with the same, slow-ish memory used by the 6502.

As Ed said, the 6800 and 6502 are unusual in having one machine cycle for each memory cycle. And IMO the Z80 has certain shortcomings, but using more machine cycles per memory cycle simply doesn't matter; you just drop in a different crystal.


Thanks for the plug! I hope it's clear that this is not a proposal but a real machine, built (and put to work) in 1988.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

My understanding is that having a large number of registers simplifies the writing of efficient register allocation/register spilling algorithms. Those algorithms are responsible for generating the machine code for moving variable values between registers and memory, and efficient versions of these algorithms make as few such moves as possible. This became far more important once the speed of memory could no longer keep up with processor speed.



This is very true. The RCA 1802 architecture had some severe limitations, particularly with regards to addressing. As I understand it, accessing memory was largely through register-indirect addressing. Memory addresses needed to be loaded into the registers R0-RF in order to access memory, which often involved a series of load immediate operations. Once the address was in a register, arithmetic and logical operations could reference the value at that address, or the value could be loaded into another R register, or into the accumulator (register D). There were R register increment and decrement operations (also in conjunction with certain load/store ops), but the arithmetic and logical operations all using involved the accumulator.



I believe the Z80 actually had a four bit ALU, as I've read Federico Faggin was trying avoid some 8-bit ALU-related patent Intel had rights to based on his earlier 8080 work. That probably played a part - at least one extra cycle for each ALU operation.

(The 1802 has a serial ALU - it takes 8 clock cycles for a machine cycle, and an instruction takes two or three machine cycles. A memory access takes just one machine cycle - but that's 8 clock cycles. As Jeff notes, we should generally scale our estimation of speed according to memory access times.)

Ouch. Think of a short pair of instructions in the 6502, which would take about 8 (machine and clock( cycles:
LDA abs
ADC abs

Memory addressing on the 1802 is limited to register indirect, and load immediate is limited to loading into the accumulator. Just setting the address in a register (R0, in my example below) would take about four instructions, at about two machine cycles each, so 64 clock cycles just to load the address into a register. That's not even halfway through the work of the 6502 example above, and we haven't even loaded a value from memory yet, nor done any arithmetic, just stuck the address into a register.

LDI abs_lo
PLO 0
LDI abs_hi
PHI 0

At a given clock speed, it wouldn't surprise me if the 6502 wasn't getting ten or twenty times as much done.

According to CPU Shack:

I'll drop this here: