BigDumbDinosaur wrote:
Hugh Aguilar wrote:
I doubt that VIRQ has any more interrupt latency than IRQ. That busy-work you mentioned (setting A with the index for use in JVM) is done in hardware, so it is instantaneous.
Nothing that occurs in an MPU (or any kind of silicon logic) is instantaneous. The internal gates in the device, regardless of how small the geometry to which the device was fabricated, have finite propagation time, which sets a very hard limit on how fast things can occur. In this case, prior to loading register "A" (an accumulator?) with an index, you have to save that register's content somewhere, e.g., on a stack, and that too takes time. These two steps have to occur sequentially, not simultaneously, in step with the clock. So, no, it will not be instantaneous.
My experience on the MiniForth was that quite a lot got parallelized and was effectively instantaneous. The processor could pack up to 5 instructions into a single opcode, all of which would execute in a single clock cycle. My assembler would rearrange the instructions in order to pack them together efficiently (with minimal NOP instructions needing to be inserted), while yet guaranteeing that the program did the same thing as if the instructions were compiled one per opcode in the same order that they appeared in the source-code.
On the MiniForth, all of NEXT got parallelized every time, so it took zero clock cycles.
My 65VM02 design is pretty crude by comparison --- this is really just a toy --- it might be somewhat useful though, for pretty undemanding applications.
The goal in adding new instructions to the 65VM02 is that instructions that would otherwise be done sequentially can be done in parallel.
LDYA and STYA are macros because the two instructions can't be parallelized, so no time is saved. I have several new instructions that do an exchange though, because that can be parallelized and should be much faster than moving data around sequentially.
BigDumbDinosaur wrote:
Quote:
If there is only one interrupt source, then the ISR can ignore A and not bother with the JVM. As for saving A to the return-stack, which is done in VIRQ but not in IRQ, almost every ISR is going to do this manually --- Garth mentioned a few cases in which the ISR didn't need to use A --- I would expect most ISRS would use A though.
True, but in "traditional" ISR programming it is the programmer's discretion as to how processing might proceed. As soon as you wire-in assumptions into the MPU itself you take that discretion away from the programmer.
Incidentally, I have written ISRs in which only .X and .Y were used and the accumulator never touched.
I would expect most 65c02 programmers to consider having A pushed automatically to be a good thing, or at least not a bad thing. You remind of how the ANS-Forth enthusiasts criticize me for writing a code-library in ANS-Forth, saying that I'm taking the programmer's discretion away from him, and that all application programs have to be written from scratch in order to be super-optimized.
There are several possible designs that are reasonable. For example, we could just have 8 interrupts, each with its own vector in upper-memory. They can be prioritized, so if two or more are ready at the same time, the high-priority IRQ goes first. If you do this, then you need 8 pins though. By comparison, with my design you need 4 pins (the VIRQ line and the 3 pins where the indicator value gets input). You could do it with 3 pins (the 3 pins are the indicator value, but 0 indicates that there is no interrupt, so you have 7 possible interrupt values). The concept of "pins" doesn't really make any sense though, because the peripherals are actually built-in to the FPGA anyway --- this is not like the old days when you had a 6522 chip sitting on the board next to the 6502 chip.
I don't really know enough about chip design to have a strong opinion on the subject of how interrupts should work. I'm just a programmer --- I have strong opinions on how software should work (high-level languages are easier than assembly-language, which is why the primary feature of the 65VM02 is supporting a byte-code VM) --- the 65VM02 would have been useful in the early 1980s when people wanted to program their Apple-II in Pascal or Forth or BASIC or whatever, but doing so was too slow, so they programmed in assembly-language instead.