On the implementation front, the first thing to check might be the relative speeds of an 8-bit and a 32-bit ALU. As we know, 6502 is almost entirely 8-bit and takes extra cycles to carry into the high byte. (The sole exception being the increment of PC, I think.)

Note also that the ROMs would have to be word-wide, unless there was a byte-wide bootstrap mode.

It might be worth collecting and ranking the various ideas which enhance the 6502 but increase the complexity somewhat. Complexity costs: in time to implement, to verify, to document and to add into the toolchain. It also may cost clock speed and gate count. (As we have CPLDs and FPGAs, the gate count cost matters only if we're overflowing some particular part and having to move up to a bigger more expensive one. For a custom chip, gate count costs area which hits yield. Chip cost is an exponential function of chip area. The original 6502 had impressively low gate count.)

Off the top of my head, for 65Org32, I quite like

predication (every instruction can be conditionally executed)
including branch offsets in the opcode
other small constant signed operands included in the opcode
including an ASL8 and maybe an ASL24 or ASL16
8x8 multiply (or 32x32 if on an FPGA with hardware multipliers)

and I also like, but would defer:

removing dead cycles
stack based address mode
RL register so all accesses are relative: free relocation
B accumulator (or just a B register)
Z register
relative JSR
putting a 16 or 24-bit address into an opcode for a new sort of zero-page
barrel shifter
prefetch buffer
top of stack held on chip
on chip cache
indirect JSR
block move
B and maybe C reg as a push-down stack: just need a POP or ROT, implicit push on every LDA. Maybe a DUP.
some byte permutations

For some choices, it matters whether or not the core is running faster than external memory, and whether or not the data bus is narrower than the operands (or opcode+operand). For a memory system which isn't simple, there are questions about flushing cache, reading back data just written, uncacheable accesses, supporting self-modifying code, and what alignment restrictions might apply. I'd defer all that.

_________________
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 thing that has not been mentioned-- is the added design complexity of the decimal mode warranted?

I haven't had any use for it in my Forth because internally it only keeps numbers in hex, and if it needs to convert the base for I/O, the conversion method works the same regardless of base, without using the decimal mode.

But some might still want the decimal mode. Maybe Lee, for EhBASIC? (I don't know how it stores and deals with the numbers internally.) How 'bout you Ruud, for Pascal? Samuel, with any of the dozens of languages you have under your belt? (I hope the heroes of the forum haven't given up reading this voluminous topic.) I don't imagine the decimal mode is very useful for Tony's game machines. Bruce, in the algorithms dept?

Someone said decimal was needed in the financial field because there was no way to precisely represent one cent as a hundredth of a dollar in hex (%0.00000010100011110101111 is about a millionth of a cent off, if I figured it right); but after working plenty in scaled integer and fixed-point arithmetic, I don't see any problem with it if internally you just make the cents the units and a dollar a hundred units (or scale it finer if you want to). Then a cent is exact.

I did use the decimal mode in a product I programmed 20 years ago; but that was in assembly language without the benefit of a HLL. I wouldn't do that kind of job again in assembly though.

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

In general, I'd prefer not to have modes. So I'd drop the feature, or add a Decimal Adjust. If not dropping it, it's a verification problem, and I've seen mention of bugs.

Specifically, if 65Org32 is built by modification of an existing 6502 design, it might be easier to retain decimal mode. The 6502 takes an extra cycle to do the decimal adjust implicitly, whereas a DAA might take two cycles to do it explicitly.

I suppose decimal mode was put in to support point-of-sale applications where code size would be very important, and I imagine it cost relatively few transistors. In 65Org32 I think it's an unwanted extra.

See this wikipedia article

If a short forward branch costs 2 or 3 cycles (and one or two words) to skip over a single instruction, then using a predicated instruction will cost 0 or 2 cycles (and saves one or two words):

is replaced by

(first example which came to mind, even though multi-word operations isn't likely to be a convincing case. Sign-extending a byte would be a better example, or the condition add in a shift-add multiply, possibly the conditional add in a non-restoring division.)

On consideration, this is a win in a pipelined machine where a branch costs more: we have the encoding space but it might not be worth it.

So I'd now drop this into the defer pile.

I was thinking of two things:

1. an evaluation stack, like an HP calculator. But that was a mistake: we don't have and I don't suggest an addressing mode to take operands off this stack.
2. automatic temporaries, like the B register but more automatic. Some code is using A, needs to do something which would need another register, and instead of PHA/PLA or similar it can just use A and then POP.

If it turns out that 65816's B register is never used, this is low value. I wasn't thinking of this small onchip stack as being at all related to the SP stack.

It's already on my defer pile.

I was thinking one can get a faster multiplication of any size if built on top of an 8x8 primitive than if doing everything by shift and add. 8x8 is small enough to hide, whereas 32x32 done in gates would be huge. A 32x32 implemented in 18x18 primitives would be fine though: so if the implementation technology has those, use them. Otherwise, stick to 8x8. (I'm implicitly rejecting any multicycle implementation: all ALU ops must be single cycle, for simplicity.)


I don't see the 65816 as helping the implementation of 65Org32 - it's interesting and it's useful, but lots of other processors are also good for ideas. We do have some 6502 implementations to use as starting points: if we're very far removed from 6502 then we have to start afresh, so count another couple of person-years for the project.

I throw in RL as a simplification and consolidation of program bank and data bank: it's more of a per-process base register, applied to all accesses, and of course is initially set to zero.

I think I'd better stop there: if I reply to everything on my defer list it'll become a very deep and wide thread!

Cheers

Here's an idea: the 65Org16 is a 6502 where every byte is 16bits. All addresses are now 32-bit, zero-page is 64k locations, as is stack, and everything else is modified in the way you'd expect. All the cycle counts (and therefore the instruction decode and datapath control) are unchanged.

The big win: implementation is derived very straightforwardly from an existing 6502.

Half the accessible memory of 65Org32, and less 32-bit performance. Fewer pins.

Of course you can write 32-bit software on this machine just as you could write it on any 8-bit micro, but you do two 16bit-byte operations instead of four 8bit-byte operations.

Cheers
Ed

How about providing multiply and divide step instructions instead of a whole 32x32 operation?

While the step approach slows down multiply it increases the speed of divide and reduces the size of the ALU logic.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

It's an interesting idea, but I'd put it in my 'defer' list, because I don't think it fits into the 6502 sequencer: it would use the ALU twice and write to two registers.

Once the sequencer admits more general instructions, it might allow for a self-repeating multicycle multiply, like the block moves. With similar questions about interrupts.

That would definitely simplify things, but I would argue that 8 bit LDA and STA should still be allowed, in addition to 16 bit versions (the index registers are, by their very nature, probably best always kept 16 or 32 bits wide). I say this after having struggled with the 65816's m/x modal architecture, it's just too annoying after having worked with the m68K, x86 and 6809, all of which allow selecting 8 or 16 bit access for free for each opcode. Many algorithms require working with 8 bit bytes mixed with wider words (eg matrix algebra where the vectors are composed of bytes and the intermediate results are kept in 16 bit words), and having to do a bunch of shifts and masks is both a drain on performance and a source of bugs.

Likewise, so no modes here. Strings are fine, once you've understood them as a stream of bytes. The bytes just happen to be wider than 8 bits. There are no alignment or shifting requirements, because memory is not addressable on 8-bit boundaries and is not being conserved, so 8-bit values are not packed but rather zero-extended or sign-extended.



There are no 8-bit bytes. If your values are small, you can hold the product in one 16-bit byte. If they are not small, you'll need some two-byte words of 32-bits, just as you used to cope on a machine with 8-bit bytes.

If you access an 8-bit peripheral, your driver (or hardware) will need to mask down to 8-bits, and maybe sign-extend. That's one or three extra instructions on each access.

In the interest of defining something which can handle 32-bit addresses but has a chance of being implemented, I'd hold 65Org16 to be a very compatible wide-byte copy of 6502. It should double the per-clock performance of 6502 when working on 16-bit or 32-bit data. It should also clock somewhat faster.

If it's ever built and anyone is interested, it could be enhanced to have a smarter sequencer, more opcodes, packed operands, etc etc. It could also be used as the base for a 65Org32 development, which would double the performance again when dealing with 32-bit data.

I think a series of implementable revisions is more likely to be a successful project.

EhBASIC does use the decimal mode but only for converting nibbles to ASCII "A" to "F" in the HEX$() function and this could be recoded not to need it.

Lee.

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