xbyte, instruction skipping, and interrupts
wmosscrop
Posts: 409
I'm using xbyte, with instruction skipping, to implement a software emulator.
If an interrupt (int1) occurs, AND I do a reti1 before the next instruction is handled by xbyte, then the skipping works.
If I DON'T do the reti1 before the next instruction is handled by xbyte, the skipping is apparently NOT honored (ignored), at least for the first instruction handled by xbyte during the interrupt. To do this, I'm JMP'ing back to where the reti1 instruction would return instead of executing the reti1 instruction. This means the interrupt is still active at the time of the next xbyte instruction.
I need to be able to, in effect, keep the interrupt state "on" until the interpreted software issues a "reset interrupt" instruction. It looks like this isn't possible.
I suspect that this is a restriction, maybe not documented?
Hardware is eval board, rev. B.
Comments
Why?! There better be a good reason to want to avoid using a RETIx.
Also need to explain what is meant by software issues a "reset interrupt".
The Parallax Propeller 2 Documentation v35 specifically states that skipping doesn’t work during an Interrupt Service Routine.
I’m not sure why you are trying to maintain the interrupt state throughout processing.
Given that you are running a software emulator, you could emulate the interrupt flag for the emulation. Then your ISR can simply set the emulated flag, clear the P2 interrupt and then return. If the last instruction in each xbyte sequence checks the emulated interrupt flag, it can branch to the emulated ISR which would be running emulated code too, right? Or have I missed something?
I've spent a lot of time on CPU emulators and I agree with AJL. It is best to separate P2 interrupt requests from emulated interrupt routines. The former, which might occur at any time during XBYTE execution, just need to set or modify a flag that is checked at the end of each emulated instruction.
This interrupt check could take only two cycles if a P2 int has not occurred by using one of the TJx group of instructions which do not modify C or Z. You could branch then check whether emulated maskable interrupts are enabled or disabled and/or test what type of interrupt it is.
A quicker alternative for purely maskable interrupts is to use
TJF int_flagas your interrupt test instruction. The emulator could set/reset 32-N bits ofint_flagfor EI/DI instructions and the P2 interrupt could set the other N bits when an emulated interrupt is due, where N is an arbitrary number of bits. In this way, the branch to emulated interrupt routine will happen only if an interrupt request has occurred and maskable interrupts are enabled.>
I'm not avoiding the RETIx, I'm delaying it.
I am emulating a machine with multiple interrupt levels (IBM 1130). for I/O devices. So the print routines (1130 interrupt level 4, which maps to INT3) can be interrupted by the disk read routines (i1130 interrupt level 2, which maps to INT1), but not vice versa. It was my intent to maintain this hierarchy.
In other words, if a print interrupt is being handled, then a disk interrupt can occur and should be handled. But the printer ISR should not be able to run until the disk ISR has finished.
On the 1130, once a hardware interrupt occurs, the interrupt state is maintained (disallowing lower level interrupts) until an 1130 "branch out of interrupt" instruction is executed by the 1130 ISR, which then clears the currently-executing interrupt level. In my emulator, at this point, I execute the RETIx (the corresponding IJMPx register has been modified to point to a "safe" return point).
So for this to work, I have to keep INT1 active until the 1130 ISR resets the interrupt. Which means spanning XBYTEs.
And obviously this won't work. That's fine. It was an experiment anyway, to see if it could be done.
Thanks to all for your responses.