Olaf Seibert

I just thought of a reason why "swap the order of the checks for interrupt vs traps" could be a bad idea. The GUI action "enter the monitor" creates a trap which enters the monitor. So if we swap the order, you'd be in the monitor before the stack operations of the interrupt. But the check for breakpoints (etc) is still at the end. So if you enter the monitor due to a breakpoint (at the same clock cycle), you would still be after the stack operations. That would create a new kind of confusion, I...

I'm not the fastest in replying either :) CPU-history Regarding how an interrupt is represented in the CPU history: as it is, the history just stores the executed instructions as the time, the instruction address, 3 bytes of instruction, and the register values. (And which cpu executed this, but we can mostly ignore that). And when shown to the user, the ordinary disassembler is used. Which means that if you want to show something that isn't an actual instruction, we're very limited, because there...

I'm not the fastest in replying either :) CPU-history Regarding how an interrupt is represented in the CPU history: as it is, the history just stores the executed instructions as the time, 3 bytes of instruction, and the register values. (And which cpu executed this, but we can mostly ignore that). And when shown to the user, the ordinary disassembler is used. Which means that if you want to show something that isn't an actual instruction, we're very limited, because there isn't really a single byte...

With both changes above, I ran a full testbench with x64sc and x64 and there were no regressions. The 0, 0, 0 in monitor_cpuhistory_store(...), it registers a BRK instruction at $FFFE or $FFFA. I guess it makes sense since an irq is really a brk. But I could fill in any instruction, if that would be clearer somehow. JMP ($FFFA) could also be a candidate, in a sense.

Algorithmix: what you describe matches closely to what I was seeing, by examining the source code. This DO_INTERRUPT macro I mentioned, when it detects that an interrupt should trigger, does indeed do the part of pushing the PC and fetching the interrupt vector. Then after that it maybe drops into the monitor. So in principle, when you're in the monitor, the PC should show that this happened, because the PC should already be the start of the interrupt routine. But it seems that this isn't very clear,...

Algorithmix: what you describe matches closely to what I was seeing, by examining the source code. This DO_INTERRUPT macro I mentioned, when it detects that an interrupt should trigger, does indeed do the part of pushing the PC and fetching the interrupt vector. Then after that it maybe drops into the monitor. So in principle, when you're in the monitor, the PC should show that this happened, because the PC should already be the start of the interrupt routine. But it seems that this isn't very clear,...

Yes I have the same hesitation... (also, having re-read the original problems, the case I described, and the expected incorrect behaviour I would expect from it, sounds a lot like number 2 instead of number 1)

Okay, so what do we with the potential changes I posted? I based them on the available test programs, not on the description in this report. Those are a bit hard to replicate by hand, and so any potential fix is a bit hard to check. We could commit the patch, if we agree it improves some things and doesn't break anything else, but I'd like to have opinions on that first. But reading the descriptions, I don't think that my patch would fix all of those. However, even if the cause of the described issues...