Hello,

I have been wondering if there was a 32bit evolution of 65816, would it stay accumulator oriented (have 1 32bit accumulator that can be subdivided into smaller ones like 816 for example) or would it have multiple full sized general purpose registers (for example 2 accumulators)?

What are your thoughts on the matter?

Some years ago, WDC published a preliminary data sheet for a 65C832, which had a 32-bit accumulator that could be reduced to 16 or 8 bits. The '832 never saw the light of day, as there really was no business case to support going forward with it—unlike the 65C816, there wasn't an Apple ready to place a volume order for product.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

_________________
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?

Hi!



No, compiler simplicity is not the reason, as register allocation is one of the difficult parts of a compiler. The main reason is that memory is a lot slower than registers, so you can't build a fast processor without enough registers.

The 6502 was fast in it's day because it has a very fast memory bus - one memory access each cycle - and has it's zero page as a "slow register area".

But the same is the reason a 6502 based design can't be made faster. For example, look at an instruction like "LDA (12), X". That instruction reads from one register (X), reads from three memory locations (12, 13 and the address calculated from those) and writes to the accumulator. That means that you can't execute that instruction in less than 3 cycles (one for each memory access), even discounting the reading of the instruction word.

Now, if you had a 16 bit register "H", you could write " LDA (H),X ", performing the same operation but with only one memory access. In a high performance implementation, you could execute that in one cycle.

That is the reason that the ARM1 was faster than most competing CPUs: the architecture has a lot of registers and the memory access was fast.

The main problem with many registers is that you need to save the registers on interrupts (making interrupts slow) and that if you want to have multiple ports in the register file (i.e., being capable of reading and writing multiple registers at the same time) the register file consumes a lot of power in the CPU. The first was solved in the ARM by having two register files that are swapped on interrupts, so you don't need to save the registers. The second was solved by having only simple instructions that read at most two registers in one cycle and write one, but even so the register file is more than 20% of the chip area: http://www.righto.com/2015/12/reverse-e ... or-of.html

Have Fun!

_________________
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?

From https://en.wikipedia.org/wiki/RCA_1802# ... ion_timing



Like the 1802, the 68K also suffered from requiring more clock cycles per instruction than many of its competitors and only somewhat making up for it with more and wider registers. Its major advantage at the time was a large address space.

The 8080/Z80 may have more registers. but data has to be moved into the single accumulator to perform arithmetic operations. And though all three register pairs can be used to access memory, there is no way to specify a displacement to the address in the pair. Accessing fields within a data structure meant having to repeatedly modify the address in a register. The Z80 came with two index registers which have displacement capability, but they are one clock cycle slower and it is somewhat inefficient to get an address into or out of them.

The two almost equal accumulators in the 680x is very pleasant to use. The 6800 suffers from having only one index register.

I have programmed many processor architectures and have worked on toy compilers for some of them.

Too few registers is a hindrance, but there is a point of diminishing return. The TI 9900 and the 68K each offer sixteen registers; the AVR has thirty two though they are byte sized.




I would like an (absolute),Y addressing mode.

Hi!


Problem is, you are still limited to one access per clock cycle. In contrast, register files are multi-ported, topically allowing two reads and one write per cycle.


No, actually the 6502 is not simpler than newer minimal RISC CPUs.

You can compare a FPGA implementation - I have a cheap "upduino" board, and build my own 6502 based computer. Using Arlet verilog 6502, I can get the 6502 core up to 16MHz, using abut 900 LUT for the CPU. On the other hand, a RISC-V 32bit core uses about 2000 LUT and clocks at about 20MHz (see https://github.com/grahamedgecombe/icicle )

And the RISC-V core executes up to one instruction per cycle, instead of the multiple cycles per instruction in the 6502, so it is *much* faster, and 3 times the number of LUT by going from 8 bit to 32 bit and from 5 to 16 registers is not that much.

The reason the 6502 core can't run faster is that the results from the ALU are directly feed to the memory address bus, so the critical path is pretty long.


The ARM cores also support two types of interrupts, FIQ is equivalent to the NMI and uses the alternate registers, and IRQ acts like the 6502 interrupts, you have to push the registers on the stack.

IMHO, I find ARM assembly simpler than the 6502 assembly, you don't have the "indirect" addressing modes, all registers are similar, and you can use condition codes to avoid jumps.

I really think that the ARM cores (in particular the old integer only ones) are the true evolution of the 6502 simplicity

Have Fun!

_________________
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?

One could look at the '832 (proposal) and the original ARM for two ways to extend a 6502 philosophy. For those who've programmed the early ARM at assembly level, and come from a 6502 background, it does feel very familiar and comfortable.

The ARM designers bore a few things in mind
- complexity is a great cost to carry especially in a small team with a tight deadline
- effectively useful memory bandwidth is the biggest influence on performance
- for fast interrupt response, shadow registers and simple instructions is a good way to go

The clock speed of the CPU is not as important as the rate at which memory accesses can be made: hence a lot of the confusion with the Z80 vs 6502, and indeed the 1802. It's memory cycles which should be counted.

ARM was a big win for a few reasons
- 32 bit wide databus
- a pipeline that's long enough to be useful but not so long it's costly and complicated
- simple regular architecture, easy to design and get right, easy to learn and use effectively
- use of DRAM page mode to improve memory bandwidth by (I think) about 30% in practice
- not constrained by backward compatibility

Not that ARM couldn't be improved on, but that's what was built. And it did come out as a big win over 68000 (especially 68008!) and NS32k. ARM has enough regularity and enough registers to be a good target for compiled code, which is another kind of win.

(Acorn, and particularly Sophie, seem to have been quite fixed in their thinking about using interrupts in a time-critical way, where other CPUs would use DMA. Having made that choice, the very long worst-case interrupt timings of the complex CPUs were a problem for them.)

The '832, on the other hand, has
- backward compatibility as a constraint
- an 8 bit bus
- no extra registers (or cache, or anything else) to relieve memory bandwidth shortage
- even fewer engineering resources and cashflow to make a go of it

For that last point: Acorn's business went through ups and downs, but was always putting resources into projects, had cashflow from the educational computer business, and could draw talent from the world-class university in the same city.

Hi. Interesting conversation. I only step in here to ask if it would be possible to create a 32 bit 65xx compatible processor, with no WDC technology at all, somehow like Compaq did in the day, creating an IBM PC compatible BIOS.

There's no problem at all with intellectual property, other than trademark (branding), as discussed recently.
viewtopic.php?f=1&t=6217

Be sure to check the various threads linked in the index post (linked above by Garth)
viewtopic.php?f=1&t=4216

Edit: I am of course quite fond of the 65Org32 idea - it's inefficient but it's straightforward to define and build. And the OPC machines have been great fun and are also relevant here:

There isn't any such instruction in the 6502.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Fortunately, it's completely obvious what is meant, and the argument applies just the same to LDA (12),Y.

Possibly of interest in relation to building wider machines but without wide memory interfaces, @hoglet found that a modest 64-line instruction cache made a major improvement to our 16 bit CPU when operated with an 8 bit wide memory.

On the topic of cache, for any implementation that isn't an FPGA, one can consider how to make use of a given transistor budget. For example, using the 4x transistor count of a Z80 and applying it to a 6502 might provide a useful amount of cache. The microcode in a 68000 can be considered as a choice: the same area budget in an ARM could be used for cache. Indeed, one can view the cached instructions on a RISC as being comparable to an automatically-tuned program-appropriate form of microcode. (FPGAs are an exception, because they are pretty large compared to our simple CPU designs, and until they are full, the size of a design doesn't change the cost at all. But in all cases, a large design is likely to support only a slower clock, and have a corresponding performance hit - unless it happens that some other part of the system limits the clock.)

To look again at the headline question: "Would a 32 bit evolution of 65816 stay accumulator based"... I think the answer is yes. To substitute a register based instruction set would be to change the machine so much that it wouldn't really be an evolution of the '816. Only to add a second accumulator would barely change the machine from being accumulator based. It might be interesting to make a machine with four registers, corresponding roughly to the facilities of the '816's A, X, Y and SP, but usually a register based machine would choose at least eight. The question would be a tradeoff of the performance of a slightly denser instruction coding, versus more memory traffic juggling values.

The ability to ADX #10 or SBS #25 or EOY #$55 would IMO be a welcome addition to the 65xx series, and I do that in my still incomplete 65m32a processor. To me, the 65xx "feel" is in the three-letter mnemonics and the single operand structure of the assembly language, not necessarily in the number of accumulator-capable registers. My largest divergence is in the elimination of indirect addressing, which is a big one, but one I can live with, due to the enhanced capabilities of the direct and immediate modes.

_________________
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)

_________________
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?