This is not a problem. I've proven it on the .b core.


I'm not very familiar with this, is it WDC65C02?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

All of the CMOS 6502's ever made had it-- Branch Relative Always, or BRanch Always-- along with STZ (store zero) and a bunch of others.

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

Zeropage is faster because the instructions are 1 byte shorter. For absolute addresses, the core has to read an extra address byte, which takes an extra cycle. Unrelated to this, the system designer could also decide to put fast memory in the zero page, and slower memory in the higher addresses, but that's a completely separate issue.

Also note the zeropage advantage isn't that big. An INC ZP takes 5 cycles, compared to 6 cycles for INC ABS. Everything in the core is the same, except for fetching the extra MSB for the ABS address.

Hi, Ed! I like the notion of destination and index fields in the top of the instruction. It seems a tidy way to add functionality to the design: extra registers, and (via the alternative indexes) extra address modes. Then I got thinking...

If the PLA and PHA instructions are among those that get destination and index fields, then that means you could (for example) Push or Pull register G using register K as the SP, is that right?

And... if the RTS instruction is among those that get destination and index fields, then that means you could RTS using register L (for example) as the SP, is that right?

My observation is that this is shaping up to be a very powerful processor for running FORTH -- far more so than the 6502 or even the 65816! FORTH is stack-oriented, of course, so the benefits of PHA/PLA variants are pretty obvious. For starters, you could have an implementation that was free to use dedicated registers for the Parameter Stack pointer, the Return Stack pointer and/or the Interpretive Pointer.

Even more exciting, the benefit of RTS variants is that you could base the FORTH threaded interpreter on dclxvi's six-cycle NEXT. This is a super-fast scheme that unfortunately, on 65816, is problematic with regard to interrupts (which make use of SP in a conflicting way). But your proposed 65ORG16.c core avoids the difficulty because it allows various registers to act as SP, eliminating the conflict.

Here I have posted a simple illustration of how RTS can thread together a list of subroutines. (This is part of a topic I created regarding a hardware work-around for the interrupt problem. The threading illustration is the only part relevant to 65ORG16.c.)

cheers,

Jeff

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

Hi Jeff
well... I do think it's right to put S into the register set. But I hadn't thought so far as to think of the stack pointer as one of the configurable registers for stack operations, although as an implementation choice it's probably quite easy.
is really a synonym for
or some similar syntax, allowing for
and offering the mental challenge of remembering which letter is the thing being pushed and which is the stack pointer.

A possible sticking point with your idea is the implicit upper 'byte' of the stack pointer. All these stacks would live together in the same page 1, which is 64k words in the 65Org16. (In the 65Org32 that doesn't happen.) Does that cause any problem or is that fine?

(To answer TT's earlier question: yes, all registers in this discussion should be pushable and poppable, which I neglected to mention, but I was commenting on the base machine which has only A, X, Y and only has the traditional PHA, PLA.)

Cheers
Ed

This idea is very interesting... An RTS suited for each register. Wouldn't this idea be most useful if the software didn't have to keep track of the stack? Meaning, maybe the 64K stack 'page' should be divided by 16 for each of the registers...

I'm not saying I can do this, or have the time right now to attempt this, but I'm sure it's not extremely difficult...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Every register should be able to cover the entire range, so you don't have to switch registers (and watch for when to do so-- what a pain that would be!) as the program advances. (Again, this stack pointer becomes a program pointer.) The software doesn't have to keep track of the stack, because for example RTS.G would do the same thing as RTS does now on S, but it would be on register G. It would load the program pointer from the the address pointed to by the address pointed to by register G (yes, double indirection), and increment G automatically as the RTS instruction does already to S.

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

Hmmm.. I did overlook the fact that SP is only 16 bits. That's a disappointment, but hardly a show-stopper. Heck, FIG Forth for 6502 uses 8-bit addresses for stacks! (The Parameter stack is in Z-pg, addressed by X, and the Return stack is in pg 1, addressed by SP).

As for the 65ORG16.c core, I think if you give other registers the same abilities as SP then the implications are very promising -- profound, even. The 6500 family has many advantages but it suffers, performance-wise, from all the bus cycles spent fetching zero-page pointers for memory addressing. So, in my opinion, anything you do that lets memory addressing occur via on-chip registers is a real advantage. Using other regs as X and Y is a bonus in this regard. But with SP the icing on the cake is the built-in auto-increment -- a real cycle-saver for searches and list processing. Moreover, SP is a reg that can be used to load the PC, so there are intriguing possibilities there.

cheers,

Jeff

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

The answer for that is a stack processsor, which has virtually no processor registers except that the stacks are in the processor itself, not out on the bus. Its machine language really is Forth. Stack processors usually do more MIPS than MHz, IOW, finish more than one Forth "primitive" per clock, without really having any pipelining. As long as we don't go that route however (which is no longer a 65-family processor at all), making the data bus the same width as the address bus means a complete address fetch takes only one clock, regardless of whether it's zero page or anywhere else in memory.

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

Yes, these are fascinating machines. (Example: the J1 processor)
I'm in favor of that. But that's the 65ORG32 project, isn't it? Maybe I'm confused

I wasn't trying to turn the 65ORG16.c into something it's not. But I did want to draw attention to the favorable implications of destination and index fields in the top of the instruction.

-- Jeff

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

As and when we have a one-byte address version of the core, it would do service both as a 65Org16 variation and as a 65Org32. So if 64k words is enough for you, or if you favour external banking schemes, that might be of interest.

Cheers
Ed