Robert Finch wrote:Nope. I got the distinction.On 2025-04-27 4:53 p.m., MitchAlsup1 wrote:I assume you are using the words interrupt and exception interchangeably.On Sun, 27 Apr 2025 11:36:05 +0000, Robert Finch wrote:>
>Representing the PC as a fixed-point number because it records which>
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.
Why not just backup to the instruction boundary ??
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.
Especially when discussing at the uArch level, I find it best to keep
these separate as the mechanisms are quite different.
External interrupts can use a single-step mechanism to stall at FetchThey are also marked done immediately do they do not get scheduled. There could be decoder exceptions (bad register usage, priv violation, unimplemented instruction). The scheduler is only looking at done and valid bits.
and wait for the older instructions to complete, so it knows there are
no older exceptions or branch mispredict purges or control changes
(eg. there is no Interrupt Disable instruction in-flight).
Exceptions are defined as synchronous with a single instruction so you
can use the Instruction Queue/ROB to synchronize older vs younger ones.
Searching for an instruction boundary in either direction is I think more logic than just recording the micro-op number. It is more FFs to record the number, but fewer LUTs. There is like 8 x10 bit comparators plus muxes on the re-order buffer to backup to the instruction boundary and mark an interrupts. Just recording the micro-op number is just stuffing 3 bits into the PC, plus three bits propagated down the pipeline (FFs). The PC has two zero bits available already.You don't need to do that back-up scanning thing or worry about
older exceptions if you transfer the exception info to the IQ/ROB uOp
as "results" and let Retire take care of it. At Retire you know
there are no older exceptions and that the committed state
managed by Retire is synchronized with this instruction's start.
An OoO instruction that executes normally will write back its results and
mark the uOp as Done. When the uOp gets to the Retire stage in the queue,
Retire sees its done so updates the committed state, PC and registers,
and removes it.
If an instruction exception occurs during execution, at write back
instead it marks the uOp as Except and records the exception number
and any auxiliary info into the uOp, such as the address that page
faulted and what R/W/E access it was attempting.
When an Except uOp reaches Retire, it sees the Except flag andGot this, called 'stomp'
- purges all the uOps in flight including the one with the exception
(so the PC and registers end up in the state they would be before
the Except instruction, making the exception precise).
Conceptually a big long CancelAll wire running to all function units
and front end stages, and halts Fetch until further notice.
- resets the future state to match the committed stateA 16-entry internal stack is being used for the PC and SR with the TOS visible. There are no memory writes then for the PC/SR so impilcit stores do not need to be performed at retire.
- Retire saves enough state (PC, stack pointer, flags, priv mode)
to restart plus saves the exception auxiliary details.
These can all be copied to privileged control registers
to be read later by the exception handler software.
- uses the exception number to select a new exception handler PC and SP
to jam those registers, and switch to Supervisor mode.
The first few instructions in the exception handler can copy the
exception info from the control regs onto the supervisor stack
(old PC, old SP, old flags, old priv mode, aux info) that the handler
needs to fix the fault and restart.
The exception handler fixes the fault if it can and restores the restartI may have to review my setup. I thought the exception handler would be able to determine what is going on given the exception PC. It can find the instruction excepting. The bad address for a page fault / privilege violation is available in the MMU via load/store instructions. There is nothing stored in the pipeline other than a fault cause code.
state (old PC, old SP, old flags, old priv mode) into the privileged
control registers. Afterward it executes a Return from Exception or
Interrupt REI instruction.
When Decode sees a REI instruction it:
- uses single step to wait for in-flight instructions to complete
- copies those privileged control registers back to PC, SP, flag, priv mode
- purges the Fetch stage so it restarts using the new PC and priv mode
Exception handler needs the auxiliary info to know what to fix.>The lead micro-ops on a interrupt return are just NOP'd out. ATM there>
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.
Also note: this is "completion" interrupt model used in 010, 020, 030
{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.
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.
b) There is no state that needs to be stacked outside of what is normally stacked for an interrupt.
Other information needed for micro-op execution is part of the ordinary state of the CPU. Micro-ops use several GPRs dedicated to micro-ops usage.
For c) the usual interrupt as well could be attacked by a thread with privilege.
>
I have coded it both ways, so I may make it a core option. Right up there with page relative branching. There is already a flag to generate the core for performance instead of size.
>
>
Les messages affichés proviennent d'usenet.