Liste des Groupes | Revenir à c arch |
On Sun, 27 Apr 2025 11:36:05 +0000, Robert Finch wrote:I think I was worried about an instruction disabling interrupts or causing an exception that should be processed before the interrupt occurred. (keeping the interrupt precise). I did not want to need to consider other exceptions that might have occurred before the interrupt.
Representing the PC as a fixed-point number because it records whichWhy not just backup to the instruction boundary ??
micro-op of the micro-op stream for an instruction got interrupted. It
was easier to restart the micro-op stream than to defer interrupts to
the next instruction.
a) is a bit worrisome. Doing something out of the ordinary is always asking for bugs. I am guessing programmers tried to manipulate the stack state on the 68k series. I replicated the 010 as an FPGA core and IIRC I stuff the machine state number onto the stack. Which is bound to be a different number than the 010.The lead micro-ops on a interrupt return are just NOP'd out. ATM thereAlso note: this is "completion" interrupt model used in 010, 020, 030
is no micro-op state that needs to be saved and restored through context
switches, other than the index into the stream which can be saved as
part of the PC.
{Not sure about 040}.
It caused:
a) a bunch of bugs
b) a lot of strange stack state
c) which could be attacked by any thread with privilege.
Although it "sounds" like it saves {time, energy, forward progress}
the state saving/restoring on the stack pretty much consumes all of
that.
Les messages affichés proviennent d'usenet.