GaBuZoMeu wrote:
INCH/DECH: I wonder whether these instruction could be useful but as following an INC/DEC. So why not implementing a INP/DEP (P = pointer, 16bit)? It would save one instruction fetch at least.
Sometimes the low byte is in Y and only the high byte is in memory. For example:
Code:
CMOVE: ; this is: CMOVE ( src dst cnt -- )
LDYA roslo,X
STYA src
LDYA soslo,X
STYA dst
LDYA toslo,X ; Y is the count, with the high-byte still in toshi,X
TST
BEQ DROP3 ; if the count is zero, don't even begin
DEY ; because we need an offset to the last element in the array (rather than past the array)
CMOVE_BEGIN:
LDA (src),Y
STA (dst),Y
SBY #1 ; clears C-flag when Y underflows (Y becomes $FF)
BCS CMOVE_BEGIN ; loop until Y is $FF
DECH toshi,X ; clears C-flag when high-byte underflows (high-byte becomes $FF)
BCC DROP3 ; loop until high-byte is $FF
STA toshi,X
INC src+1
INC dst+1
BRA CMOVE_BEGIN ; this loop could be unwound to boost the speed
GaBuZoMeu wrote:
IRQ latency: As BigEd already said, its µs (or less) today. Several priorities might be nice, but vectoring is more important. If you need to poll where the IRQ is coming from you lost. If your CPU shall compete against any modern microcontroller vectoring is mandatory. And then one or two sets of shadow registers per priority might be sufficient.
Well, I now have 8 MIRQ interrupts --- that seems like a lot to me.
GaBuZoMeu wrote:
Another way to speed up response is DMA. If information is just to gather or to refresh DMA can do that in a virtual° transparent way. (° setup, maintaining, and stolen cycles are the "costs")
DMA is what the coprocessor essentially does --- moves data between I/O ports and circular buffers in far memory --- but with the coprocessor the user writes the code for the coprocessor, so he has some flexibility in what he can do, rather than have this written in HDL.
Note that a coprocessor doesn't speed up I/O at all. What it does, is speed up the main-program because the main-program is not being interrupted to do the I/O.
GaBuZoMeu wrote:
No more multi tasking support / no D register: why?
The big problem with the D register is that every task has its own direct-page, which means that tasks can't have shared direct-page variables. I was worried that this was going to kill the speed --- the 65c02 has always benefited by keeping important global variables in the direct-page --- pointers are especially useful in the direct-page because of the (direct) and (direct),Y addressing modes.
EDIT: Another thing I want to mention, is that it may be possible to have the lower 512 bytes of memory to be faster than the rest of memory that has a wait state. Having the whole program use the zero-page as the direct-page and the one-page as the return-stack will channel a lot of data through the lower 512 bytes of memory, rather than having it scattered all over the memory map as it would be given the D register.
The multi-tasking OS and the D register would have been useful for huge programs in which each task needs its own direct-page and there wouldn't be enough room in a single direct-page for the entire program --- such big programs seem unlikely though --- most programs don't need this level of complexity.
GaBuZoMeu wrote:
Of course multi tasking cannot render interrupts as useless. But having intrinsic support for rapid task switching is valuable and something that isn't a common feature in the microcontroller world. Having multi tasking support you can use ISR for immediate response / quick action but everything that doesn't need to be done in that pace can be delegated (by the ISR) to an appropriate task (e.g. sending a message, setting a semaphore or flag, ...). The ISR could issue a request to the task scheduler to elevate its associated task(s). There are many other possibilities how ISRs and tasks could work in a cooperative fashion making the systems look & feel more agile.
Well, people can still do a cooperative round-robin multi-tasker as done traditionally in Forth.
Another issue here, is that I don't really know anything about preemptive multi-tasking OS systems. This was getting beyond my level of expertise --- I got rid of the D register and the multi-tasking support just to simplify the system, to a level I'm more familiar with --- there may be some big programs though, that the 65VM02 would no longer be capable of supporting.
This is my first design --- I don't want to go overboard with features --- I don't want to "invent" the ARM Cortex.
Login
Register
FAQ
Search
The 65c02 has always been weak on 16-bit data. Some of these instructions only provide a minor benefit. For example, DINX DDEX PHYA PLYA are all examples of new instructions that only replace two old instructions, so only a tiny boost in speed. All of these are in critical places in the code though. PHYA and PLYA are used by CALL and WEXIT which are important in Forth. Note that CALL and WEXIT are likely to be exactly the same in C or Pascal --- CALL pushes the old IP to the return-stack and sets IP to a new address, and WEXIT undoes this --- that is going to be the same in any language, and pretty important.
