65VM02

[Rob Finch]

Quote:

Arlet wrote:

Quote:

GaBuZoMeu wrote:
Perfect could as well be a driving force to let good advance to better

True, but it's better to build a good system first, and perfect it step by step. It's too easy to come up with many great ideas from the start until you're overwhelmed and quit.]

One has to start somewhere. It's better to build a crappy system first which can then be improved to a good system. One may not know what a good system is until one's seen a few crappy ones.

[BigEd]

Thomson's Rule for First-Time Telescope Makers: "It is faster to make a four-inch mirror then a six-inch mirror than to make a six-inch mirror."

[GaBuZoMeu]

Hugh Aguilar wrote:

What you are describing is something I had in an early version, but no longer have.

Previously I had expected to have a T-flag that gets set by the heartbeat timer (either the ISR does this, or it is done by hardware). At NEXT for every primitive (not any particular frequently used primitive), the T-flag is tested and if set a task-switch is done.

I got rid of all that though.

There were problems with that design. Specifically, that accessing some shared resource could only be done inside of a single primitive, which necessarily implied that the code was written in assembly-language. What I have now is the EXA instruction that allows a task to obtain a semaphore. This means that accessing some shared resource can be done in Forth code (or C code or whatever language is being used) --- it doesn't have to be done inside of a single primitive --- the whole point of the 65VM02 is to support high-level languages, so I don't want to force people to use assembly-language for common programming tasks.

I think my design is way beyond the 65c02. I have support for byte-code VM execution which makes a high-level language realistic, I have support for local variables, I have support for semaphores, and I have support for a RAM-disk outside of the 64KB main-bank. The 65c02 lacked support for all of this --- that is why it became obsolete --- it was a very minor upgrade to the 6502; it just wasn't moving forward into the future.

The 65c816 is a much bigger processor than the 65VM02, with 16-bit registers. It doesn't support byte-code VM execution though, so high-level language compilers will typically generate machine-code which is typically quite bloaty. The 65c816 also only has the NMI and IRQ interrupts, the same as the 65c02, so it is pretty weak compared to the 65VM02 that has NMI IRQ MIRQ0 MIRQ1 MIRQ2 MIRQ3 interrupts --- the 65VM02 also allows NMI and IRQ interrupts to interrupt MIRQ ISRs, although the MIRQ interrupts can't interrupt each other's ISRs, so I have a distinction between high-priority and low-priority interrupts.

In the 65VM02 I have the D register that indicates where the direct-page and return-stack are. The D register is always even, so the direct-page will be on an even page and the return-stack will be on the next higher page. By changing D the entire context of a task can be swapped out with that of another task (most tasks use only the direct-page and return-stack for all of their data). This makes for very fast task-switches. The tasks communicate with each other using shared data-structures in the heap (there is 56KB of RAM available in the main-bank, so the heap is pretty big).

The 65VM02 is still an 8-bit processor with 8-bit registers. It is not an upgrade to 16-bit registers like the 65c816. It seems like upgrading from 8-bit to 16-bit registers is obvious. I am dubious that this is a good idea though. To me, the hallmark of the 65c02 was the A X Y and S registers, all 8-bit, and that is what I still have in the 65VM02 (with the addition of the D register that is also 8-bit). This is a small processor! I do have the IP register that is 16-bit, but this is provided to support byte-code VM execution, which is only necessary for high-level languages support.

Having a very few 8-bit registers allows the 65VM02 to have very fast interrupt response time (the IP registers doesn't have to be saved and restored if the ISRs are written in assembly-language, which is the typical case). All in all, I think the 65VM02 is a better design than the MSP430 or STM8 --- those are primarily what it would compete against.

OK, I have read that you were tinkering with your T-flag but I didn't notice that you dropped it. I thought the new M bit serves to distinguish between various IRQ levels AND somehow serves as a "time to switch task when it's convenient" flag. This is obviously not the case - so, how do you organize multi-tasking now? Or did you drop it?

Your new EXA instruction could well serve for more purposes than just semaphore handling. Of course some more address modes for EXA would be nice. BTW TSB/TRB lacking the (ptr),Y address mode but else could handle semaphores as well.

AH, and I have read your "65VM02.TXT" - now I know that NEXT is just a macro appearing at the end of many?most?all primitives and therefor would have been a good termination point - like the way the processor itself is checking the NMI and IRQ signals before fetching the next instruction.

[Hugh Aguilar]

Rob Finch wrote:

Quote:

Arlet wrote:

Quote:

GaBuZoMeu wrote:
Perfect could as well be a driving force to let good advance to better

True, but it's better to build a good system first, and perfect it step by step. It's too easy to come up with many great ideas from the start until you're overwhelmed and quit.]

One has to start somewhere. It's better to build a crappy system first which can then be improved to a good system. One may not know what a good system is until one's seen a few crappy ones.

I don't know what system you guys are talking about, so I don't know if this is a crappy, good or perfect system

Do you have some particular application program in mind? I don't. I'm just trying to design a general-purpose processor. The 65c02 was always general-purpose, and the 65VM02 is an upgrade on it.

[Hugh Aguilar]

GaBuZoMeu wrote:

OK, I have read that you were tinkering with your T-flag but I didn't notice that you dropped it. I thought the new M bit serves to distinguish between various IRQ levels AND somehow serves as a "time to switch task when it's convenient" flag. This is obviously not the case - so, how do you organize multi-tasking now? Or did you drop it?

It is preemptive now. A task-switch can occur in the middle of a primitive.

GaBuZoMeu wrote:

Your new EXA instruction could well serve for more purposes than just semaphore handling. Of course some more address modes for EXA would be nice. BTW TSB/TRB lacking the (ptr),Y address mode but else could handle semaphores as well.

Well, EXA could be useful for exchanging memory blocks, such as in an array sort function. This would use (direct),Y addressing though --- I can't think of any reason why any other addressing-mode would be needed --- I don't want to add instructions to the 65VM02 on the vague idea that they might prove useful, if I can't think of any specific use for them.

[GaBuZoMeu]

Well, exchanging stacked items without requiring auxiliary memory or registers would be easier using abs° or S,offs. (°: in the case of 65VM02 this probably won't work as your D reg moves the stack as well so absolute addressing the stack won't work and dp addressing stays in dp (?).) Perhaps (direct) - without Y - but no matter, of course it is up to you what you add to your design.

[Hugh Aguilar]

GaBuZoMeu wrote:

Well, exchanging stacked items without requiring auxiliary memory or registers would be easier using abs° or S,offs. (°: in the case of 65VM02 this probably won't work as your D reg moves the stack as well so absolute addressing the stack won't work and dp addressing stays in dp (?).) Perhaps (direct) - without Y

I use direct,X for accessing the data-stack. Exchanging items on the stack needs Y available, but this is not a problem because Y is available:

Code: Select all

SWAP:               ; ( a b -- b a )
    LDA toslo,X
    LDY soslo,X
    STA soslo,X
    STY toslo,X
    LDA toshi,X
    LDY soshi,X
    STA soshi,X
    STY toshi,X
    NEXT

The typical reason that Y is not available, is because Y is being used for (direct),Y addressing, such as in an exchange of a blocks of memory. In this case the EXA (direct),Y instruction comes in handy.

GaBuZoMeu wrote:

- but no matter, of course it is up to you what you add to your design.

I want input from you guys. I have already gotten good ideas --- for example, we have Garth saying that there should be high-priority interrupts that can interrupt the ISRs of the low-priority interrupts --- I've made changes to the design because of input I've gotten from this forum.

A lot of you guys have more experience with 65c02 programming than I do. You've stuck with the 65c02 for all of these years --- I haven't really given any thought to the subject since I wrote that Apple-IIc program to do symbolic math way back in about 1990 --- now I'm interested in the subject again, although why I'm on this 65c02 kick in the year 2017 is hard to explain...

[GARTHWILSON]

Hugh Aguilar wrote:

now I'm interested in the subject again, although why I'm on this 65c02 kick in the year 2017 is hard to explain...

enso seemed to explain it well, at viewtopic.php?f=12&t=2682&p=35151#p35151 .

[GaBuZoMeu]

Remarkable words from enso!

[GaBuZoMeu]

Hugh Aguilar wrote:

I want input from you guys.

Well, you created

Code: Select all

JVM page            jump through the pointer located at (page*$100+A)

I would think about

Code: Select all

JVM page            jump through the pointer located at (page*$200+2A)

Don't know whether twice as much primitives makes sense.

The D-register could span from A9..A16 instead of A8..A15. Increment D then means D := D+512. This would extend the direct pages even into the alternate bank, doubles the number of possible separated tasks - I don't speak Forth, so no idea whether this could be of any use.

[Hugh Aguilar]

Hugh Aguilar wrote:

GaBuZoMeu wrote:

Well, exchanging stacked items without requiring auxiliary memory or registers would be easier...

I use direct,X for accessing the data-stack. Exchanging items on the stack needs Y available, but this is not a problem because Y is available:

Code: Select all

SWAP:               ; ( a b -- b a )
    LDA toslo,X
    LDY soslo,X
    STA soslo,X
    STY toslo,X
    LDA toshi,X
    LDY soshi,X
    STA soshi,X
    STY toshi,X
    NEXT

Well, I've given some thought to GaBuZoMeu's suggestion and I think that I will upgrade EXA to support the direct,X addressing mode. When I do this, I get:

Code: Select all

SWAP:               ; ( a b -- b a )
    LDA toslo,X
    EXA soslo,X
    STA toslo,X
    LDA toshi,X
    EXA soshi,X
    STA toshi,X
    NEXT

This is two instructions shorter, and SWAP is a very common Forth word, so this is worthwhile.

With ROT the difference is even greater:

Code: Select all

ROT:                ; ( a b c -- b c a )     ; without EXA
    LDA toslo,X
    LDY soslo,X
    STA soslo,X
    STY toslo,X
    LDA toshi,X
    LDY soshi,X
    STA soshi,X
    STY toshi,X     ; -- a c b
    LDA toslo,X
    LDY roslo,X
    STA roslo,X
    STY toslo,X
    LDA toshi,X
    LDY roshi,X
    STA roshi,X
    STY toshi,X     ; -- b c a
    NEXT
    
ROT:                ; ( a b c -- b c a )     ; with EXA
    LDY toslo,X
    LDA soslo,X
    EXA roslo,X
    STA toslo,X
    STY soslo,X
    LDY toshi,X
    LDA soshi,X
    EXA roshi,X
    STA toshi,X
    STY soshi,X
    NEXT

I'll hold off on a new update on the document because this is a minor change. I may have some other changes to do.

This upgrade, adding the direct,X addressing mode to EXA, is Forth-centric --- I doubt that it would help C at all.

I would be interested adding instructions to help C compilers produce better code. I'm not familiar with C for the 65c02 however, so I don't know what would be helpful. Do any of you have experience with C on the 65c02, or are all of you only interested in assembly-language programming?

[GaBuZoMeu]

IMHO the problem of translating C (and many other tongues, even Forth!): to be universal they use a universal model and that is always ever stack oriented. And that is something, the 6502 does not support natively. The power of Forth lies in the mental strength of its programmer - (s)he has an overview about what will happen in the near future and plans the processing accordingly. This is an enormous advantage against a machine thats deals with characters and keywords. That is why Forth is/seems to be so powerful which in turn causes the people to like it

I would assume that every addressing mode concerning the return stack and/or every new instruction that helps processing sw-stacks would be helpful. Like INP direct, DEP direct (increment/decrement a direct pointer (16 or more bits) in a RMW fashion) might be helpful. Adding an S-relative address mode (ADC S,3 or DEC S,6 ...) should be a very powerful way to enhance the 6502's capabilities.

my 2 cents

[Hugh Aguilar]

GARTHWILSON wrote:

Hugh Aguilar wrote:

now I'm interested in the subject again, although why I'm on this 65c02 kick in the year 2017 is hard to explain...

enso seemed to explain it well, at viewtopic.php?f=12&t=2682&p=35151#p35151 .

I can relate to enso's nostalgia for the C64 and Apple-IIc etc..

This isn't my motivation for the 65VM02 though, because I'm thinking of a micro-controller, not a personal computer.

I think I like the 65c02 because of the direct-page pointers. All of the other processors have a few 16-bit registers that can be used for indirect access of memory (the AVR has 3), but the 65c02 has a pretty much unlimited number of them --- how cool is that?

I'm expecting the 65VM02 to be mostly competitive against the MSP430 (the AVR too, but the AVR is fading away). Even thought the 65VM02 is 8-bit and the MSP430 is 16-bit, it should be competitive --- having only a few 8-bit registers speeds up interrupt response time a lot, and having a D registers makes task-switches fast.

The 65VM02 could be the next big thing --- actually, the next small thing, as it is a small 8-bit processor.

[GaBuZoMeu]

Hugh Aguilar wrote:

The 65VM02 could be the next big thing --- actually, the next small thing, as it is a small 8-bit processor.

This becomes "the next BIG THING" doesn't it?

[Hugh Aguilar]

GaBuZoMeu wrote:

IMHO the problem of translating C (and many other tongues, even Forth!): to be universal they use a universal model and that is always ever stack oriented. And that is something, the 6502 does not support natively. The power of Forth lies in the mental strength of its programmer - (s)he has an overview about what will happen in the near future and plans the processing accordingly. This is an enormous advantage against a machine thats deals with characters and keywords. That is why Forth is/seems to be so powerful which in turn causes the people to like it

I would assume that every addressing mode concerning the return stack and/or every new instruction that helps processing sw-stacks would be helpful. Like INP direct, DEP direct (increment/decrement a direct pointer (16 or more bits) in a RMW fashion) might be helpful. Adding an S-relative address mode (ADC S,3 or DEC S,6 ...) should be a very powerful way to enhance the 6502's capabilities.

my 2 cents

Well, for the Forth local-frame, I have the LF direct-page pointer. I provided the LLY instruction for obtaining the base of the return-stack data, and I provided the AAS instruction for discarding local-frame at the conclusion of the function. Would a C compiler do this any differently?

In my system, locals are accessed with (LF),Y addressing. In your system, locals would be addressed with S,offset instead. This may be slightly faster, as (direct),Y is a slow addressing-mode. The problem with your system is that this would not support quotations and HOFs --- this is a major feature in my Forth --- this isn't supported in C though, so not an issue there.

EDIT: I have read that GCC does support something like quotations and HOFs as one of its several non-standard extensions to ANSI-C. Is anybody here familiar with GCC? Is anybody here familiar with any particular C compiler for the 65c02? Are there any in the public domain?

As for INP and DEP --- those could be useful.
I don't want to add new instructions unless I have a specific piece of code that would benefit, and that piece of code is speed-critical. I don't want to get carried away and add new instructions that seem useful, but end up not being used or only being used in code that doesn't matter very much anyway.

Another point is that I am dubious about working with 16-bit data internally. This might be difficult to implement in HDL. This is why I changed JVM to only support 128 primitives rather than 256 primitives. I don't know enough about HDL to know if I'm actually helping anything though.