That interrupt latency is extended by an instruction execution period is far less of an issue than if the system comes to a halt due to a stuck interrupt request line.

_________________
Michael A.

And at 100MHz even 7 cycles isn't too great an extra penalty.

I don't see why it would come to a halt. The IRQ handler removes the source of the interrupt, and then it'll execute the next instruction(s). If the interrupts happen so quickly that there's never time to execute any more instructions, the system is badly designed.

I don't know how many times I've had to dig out software designs which require fast interrupt handling from a microprocessor to operate correctly. Generally, these situations arise when the hardware being serviced has too small a buffer, and a quick response is needed to preserve the data. It's amazing how slow PCI and ISA busses are compared to the processors connected to them. Furthermore, I don't know of a single processor that can multi-thread its I/O and memory busses; so if the I/O transactions are performed in SW, the processor is operating for a significant portion of time at the transaction speed of the I/O bus.

However, a much safer and less problematic solution is to improve both the hardware and the software. For example, I don't know how many times I've brought a PC (MS-DOS/Windows/Linux) to it's knees servicing a simple 16C550 UART receive queue. Some additional buffering implemented in a custom UART, coupled with a block move ISR, easily relieves the bottleneck on the bus and frees the power of the processor to be applied to processing of the data stream. The interrupt latency requirements are then dramatically less stringent, and everything operates on a much better schedule.

_________________
Michael A.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

It would still result in severe degradation of processing power for the main program, not to mention the impact of the continuously missed interrupt service for an IO resource.

Wether you stall or crawl will not make that much of a difference.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

BDD - have you studied the 6502 implementation? Do you understand NMOS logic and the basis of the visual6502 simulation? You're very quick to suppose that you know better.

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

But it should allow the main program to reach an SEI at some point without extraordinary effort; albeit quite slowly.

Once you turn on an interrupt, you've wandered off the reservation anyways, and all the dragons and sea serpents that will appear as a consequence will be there because you invited them in.

Furthermore, it is very common for the main program to disable/enable interrupts in order to access common data structures between itself and the ISR(s). Under these circumstances, I don't think that it's realistic to express concern regarding the additional latency introduced by allowing the instruction at the return address to execute before the ISR is re-entered. The latency introduced by the enable/disable sequences of the main program are likely to be much longer than that of the longest executing 65C02 instructions, e.g. 7 or 8 cycles for jmp (abs,X).

If the hardware and the software are well synchronized so that there's no need to enable/disable the interrupts, then interrupts are a convenience and not a necessity. The question then becomes is how much time is the main program spending waiting for the interrupt to occur.

Finally, the service time jitter introduced by the use of SEI/CLI to access critical regions should be on the order of 50, 100, or more clock cycles for any processor performing any meaningful work in an interrupt driven environment. The jitter has to be a fraction of the interrupt rate and interrupt service time in order for there to be any processing time available for the main program to perform any meaningful work.

Given all of the effects that can affect the regularity of interrupt service routines, I don't consider using interrupts for timing or sampling of events which require precision greater than about 1000 clock cycles. For those types of events, I use hardware timers and independent hardware feeding into, or being fed from, FIFOs/queues. That's not to say that there's not a place for interrupts in these type of tasks, but it's that I lean toward a blended solution between custom/semi-custom HW and SW.

Thus, if I were to use interrupts in the manner that Garth described for audio sampling, then I would be concerned about the additional latency that my design decision for the M65C02 core might introduce. However, the core is targeted at FPGAs, and as a consequence, it is not just the core but any additional logic that may be required by an application that will be included in the FPGA. If the core was intended as a general purpose processor, then I would consider changing the mix of interruptable and non-interruptable instructions. I expect that only the interrupt handling microsequence and the microsequences of the program flow control instructions would need adjustment; no change required to any of the logic.

_________________
Michael A.

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

On modern systems this can be a problem too. I've done several projects on ARM where it takes a few cycles for the I/O write to make its way through the internal pipeline. So I'd turn the interrupt source off, and return from the ISR, only to be hit with the same interrupt again.

On a recent project, I made a PWM controller for 4 H-bridges, with the CPU controlling each leg of the H-bridge, for a total of 16 control lines. Since the microcontroller didn't have enough PWM hardware, and I didn't want to add an external CPLD/FPGA, I used 16 GPIO lines and a timer interrupt. In the graph you can see the interrupt performance. Both edges of the waveform are controlled by a timer interrupt. I let the scope run for a few minutes, collecting all the data. Each of the software PWMs ran at 50kHz, resulting in 250000 interrupts per second, and with a requirement for minimum jitter.

.

It's true that instructions are indivisible, meaning an interrupt won't be permitted in the midst of an instruction's execution. However, interrupts routinely begin after an instruction opcode is fetched yet before that instruction commences execution. This is laid out in the section of the data sheets detailing cycle-by-cyle execution of all instructions and the interrupt acknowledge sequences. See Table A. 5.4 on page A-11 of the MOS Hardware Manual; also Table 5-7 of the '816 Data Sheet (the entry under Address Mode 22a. for ABORT, IRQ, NMI, RES).

The interrupt sequence begins just as an op-code is fetched. Specifically, SYNC is high (on the '816, VPA=VDA=1) and a memory read occurs. But that opcode is ignored -- apparently replaced (by internal logic) with a BRK opcode.

Since the original opcode has been fetched but ignored, some means is required to assure that it is not skipped altogether. Ie; it needs to execute later. Hence, as shown in the tables, the PC is not incremented following the fetch of the discarded op-code. (This is an anomoly, since the PC is usually incremented following every opcode fetch.) Of course the PC is pushed then later popped after the interrupt has been serviced, so the very same instruction fetch will occur again.

In light of this information the simulator's behavior seems entirely plausible. If there's any remaining doubt, a trivial experiment with an actual CPU would quickly settle the matter. Certainly I've seen nothing in the data sheets to suggest the same instruction can't be pre-empted repeatedly if circumstances again (or still) demand an interrupt.

cheers
Jeff

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

It might be worth mentioning that the visual6502 simulation is truly a simulation - it models the behaviour of the several thousand transistors which make up the NMOS 6502. With the exception of the unassigned opcodes, it can be expected to behave exactly as does the chip.
Cheers
Ed