Improving the 6502, some ideas

[BigEd]

Hi Mike
just wondering: is this a paper design, or do you have some way of simulating it?
I was able to cook up an online simulation of 65Org16 and 65org32 by modifying the easy6502 emulator: it just might be worth doing the same for 65m32.
Cheers
Ed
ps. see http://biged.github.io/6502js/ online and the source at https://github.com/BigEd/6502js

[barrym95838]

BigEd wrote:

Hi Mike
just wondering: is this a paper design, or do you have some way of simulating it?

Hi, BigEd.

This is a paper design, but one that really excites me. I have an old degree in Computer Engineering from well over 20 years ago, and ideas about efficient, programmer-friendly designs have been floating around in my head since I learned 6502 assembly as a teenager. This design (especially the very flexible operand structure) is therefore deeply imbedded in my brain, and difficult to express clearly to potential audiences. I thought that my 6502-to-65m32 instruction translation teasers and code fragment teasers might generate some interest, and encourage me to finally get the full picture out of my head and onto paper.

As I mentioned in the Introduce yourself thread, I have been messing around with CPUSim, hoping to be able to get a working simulation. It's easy for a brutally simple processor like the Wombat, but much more difficult for something useful like the 6502. I'll keep trying, and hopefully come up with a mature description suitable for human (or simulator) consumption. Hardware implementation is a distant dream, although ttlworks' dearly-departed TREX is an inspirational (although sad) story. I'm not ashamed to admit that I fought back a tear or two when I read it. Many years ago, I had the same reaction when I first fully understood the PDP-11's operand structure and implementation. Yep, I'm definitely a nerd!

Sincerely,

Mike

[BigEd]

Oh yes, sorry, I'd forgotten your intro... No problem with your design presently being on paper, I just wondered. I have no idea whether cpusim or easy6502 or something else would be the easiest way to get a model running.
Cheers
Ed
(TREX: http://6502.org/users/dieter/trex/trex.htm)

[ttlworks]

The TREX concept was influenced by the architecture of some Forth CPUs.

The basic idea was, to find an architecture for a CPU core which
would be as simple as possible, while still being able to run
"some serious software"... whatever that means.

...and I admit, that I had no concrete plans for "morphing"
6502 machine code into TREX machine code in real time.

A detailed description of the TREX instruction set can be found here:
http://6502.org/users/dieter/tinst/tinst_0.htm

It's nice to hear that my old design was inspirational to others,
so the effort on building TREX wasn't wasted.

[MichaelM]

Pretty cool.

The link register concept is reminiscent of the PDP-6 and other processors of that era.

[teamtempest]

Quote:

I have been messing around with CPUSim, hoping to be able to get a working simulation. It's easy for a brutally simple processor like the Wombat, but much more difficult for something useful like the 6502.

I was playing around with CPUSim a while ago, toying with the idea of a 6502 with 16-bit registers, a 16-bit "byte" size and only 64KB address space. It was a little tough to get going, but once I got the hang of it things seemed to go pretty well. Especially once I started noticing repeated patterns in the sequences of microinstructions, it became easy to write new "high level" instructions (ie., your standard 6502 mnemonics) by cloning an existing instruction and making a few changes. For example, once you've got DEC absolute, it's easy to write DEC absolute,X, INC, INC absolute,X, and so on.

I found CPUSim to be quite flexible once I got used to it. I might be able to answer a few questions about it. Not about register arrays, though, since I didn't use them - I just made as many discrete named ones as I wanted.

[barrym95838]

teamtempest wrote:

I found CPUSim to be quite flexible once I got used to it. I might be able to answer a few questions about it. Not about register arrays, though, since I didn't use them - I just made as many discrete named ones as I wanted.

Awesome! The user interface takes some getting-used-to, and I reached several stumbling blocks, all seemingly unrelated. I think that it stemmed from the fact that the distribution didn't include any foundation more complex than the Wombat from which to build/modify (which was the recommended development process for beginners). I suppose that I could have e-mailed its creator and asked for different foundations, but your offer to help may make that unnecessary! I don't know how you would feel about PMing me one of your attempts for me to examine and play with, but I hope that it doesn't hurt to ask!?!

Thanks,

Mike

[Edit Alert: I have tried to begin following Jeff's advice, and have started by adding several explanatory paragraphs near the end of my initial post on this thread, on Page 9.]

[BigEd]

Here's the start: viewtopic.php?f=1&t=1419&start=125

I'd be happy to see you start a new 65m32 thread.

Cheers
Ed

[barrym95838]

BigEd wrote:

I'd be happy to see you start a new 65m32 thread.

I trust your experience and judgment. Where does it fit. Here, there, at anycpu.org ... ?!?

Mike

[BigEd]

Hmm, perhaps General - then in the programmable logic section if we get to FPGA thoughts.
A post at anycpu.org pointing back here, perhaps?

[MichaelM]

I had thought you might suggest Emulation and Simulation as that appears to be the current thinking on how to work out the details of the CPU he has in mind.

[BigEd]

Hmm,maybe there is no one right answer. The 65Org32 has a presence in several categories...

[GARTHWILSON]

For where the nature of the discussion at this point, "General" would probably be best. As things progress (which I hope they do), it will get simulated, then put into programmable logic and hardware. All along, there will be programming considerations. As it gets closer to reality (which I hope it does), there will be a need for an assembler, then other software, and then maybe an SBC project... That covers a lot of categories; but we're not there yet. "General" is probably best for now.

[barrym95838]

GARTHWILSON wrote:

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.

Okay, one more code fragment teaser for Garth, then I have some serious work to do on my documentation and CPUSim package. Thanks to teamtempest for kindly sharing his 16-bit CPUSim core with me ... I think that he probably saved me several hours of tinkering and cussing.

Code: Select all

        loop:
:bd0c0000       inc  ,s         ; increment index on rTOS
        checkend:
:410c0000       lda  ,s
:c10c0001       cmp  1,s        ; compare incremented index to limit
:5c5e000a       bcs  quitloop   ; if index >= limit, loop is complete
        contloop:               ; else loop around: 
:4d060000       ldy  ,y         ;   load IP with loop back address
:5e060000       jmp  (,y+)      ;   and proceed
        +loop:
:410c0001       lda  1,s
:150c0000       add  ,s         ; update the index by the incrementer.
:810c0001       sta  1,s
:420c0000       lda  ,s+        ; pull incrementer and check sign
:5caffff6       bpl  checkend   ; if + then do a forward compare
:410c0001       lda  1,s        ; else
:c10c0000       cmp  ,s         ;   do a reverse compare (limit >= index)
:5c4ffff6       bcc  contloop   ;   for end-of-loop check
        quitloop:
:9108????       stz  LOOP_LEAVE ; show that LEAVE was not used to exit
:4d0c0002       ldy  2,s        ; load IP with end addr from the rstack
:580c0003       lds  #3,s       ; discard index, limit, and end address
:5e060000       jmp  (,y+)      ;   from rstack and proceed.

This isn't really a fair fight, but it looks like 18 words of code on my 65m32 are doing the same job as about 231 bytes of code on the 65c02. The reason that it's not fair is because the 65c02 is not in its native 8-bit element here, and is bogging down on multi-byte stack items. For a more accurate efficiency comparison, it might be more helpful to compare the 65c816's implementation of a 16-bit loop/+loop combo, since that would level the playing field regarding native word size, and concentrate more on how efficient my operand scheme is, and whether or not there is room for improvement. Of course, I'm its proud father, so I'm somewhat biased ...

Mike

P.S. Regarding a normalized 65c816 vs. 65m32 code efficiency comparison: The 'm32 has only its unique operand structure (with embedded constants), while the '816 has the advantage of being able to pack up to two complete instructions in 16-bits, plus its indirect addressing modes, which are missing from the 'm32. It beats the 'm32 for fetch (@) when judging strictly by normalized code density ... how do you think it will pan out for something more complex?

P.P.S. Perhaps it would be an interesting exercise for me to try leveling the playing field the other way, by coding a 128-bit version for the 'm32? Nah, that's not a good use of my spare time ... I need to get my specs ready for a new thread A.S.A.P.

P.P.P.S. As I was drifting off to sleep last night, it occurred to me that there could be a minor bug in the above fragment; I believe that it handles negative increments properly, but will probably choke on a negative index and/or limit. Those of you with 6502 experience should be able to see it, so I'll leave it in for now ... there's no danger in it, since it has no host on which to run ... yet!

[EDIT 2013.10.07]: jmp (,y+) is not a proper ITC NEXT, since IP points to the CFA, not the actual machine code. It needs to be replaced with:

Code: Select all

NEXT    (2 instructions, 2 machine words, 5 cycles)
        ldu  ,y+        ; W = (IP) , IP += 1	
        jmp  (,u+)      ; execute code @ (W) , W += 1

[GARTHWILSON]

[Edit: Darn! I see I already brought this up, near the top of page 10 (although more briefly). I won't delete this post however since there's already a response to it.]

For any of these improved-6502 processors-- Is it feasible to add interrupt-vector registers, so part of the job of the reset sequence (if automatic) or reset routine (if in the user's program) would be to transfer the vectors to processor registers, to eliminate the need for extra bus cycles in the interrupt sequences to read them? It's not just to save cycles, but cycles that might need wait states if left only in ROM. Then there would be no need to ever access slow (E)EPROM after the reset routine has finished. We've talked before about copying ROM to RAM and then paging out the ROM and kicking the clock speed up, but this should simplify the hardware design.

A smaller step might be to keep the interrupt vectors in RAM (instead of processor registers), but in addresses that are never ROM, even at reset. They could be the first addresses starting at 00000000 for example, and the reset routine would fill them in. Not having them in place yet at reset is no problem, because the interrupt-disable bit(s) should be set at reset, and peripherals not yet enabled to produce interrupts at that time.

Another advantage of course is being able to change them on the fly.