From Newsgroup: comp.arch

On Sat, 05 Oct 2024 17:57:12 GMT, [email protected]
(Anton Ertl) wrote:

Ok, it's more efficient to insert an interrupt call into the
instruction stream in the decoder: all the in-flight instructions will
be completed instead of going to waste. However, the interrupt will
usually be serviced later, and, as you point out, if the instruction
stream is redirected for some other reason, you may have to replay the >interrupt.

A _trap_ can be a problem on an out-of-order machine, since traps
result from exceptions, and so they have to be tied to the instruction
stream.
An interrupt, on the other hand, just needs to get serviced. The
process being interrupted just needs not to be disturbed by it.
That leaves several alternatives.
You could somehow make the machine act as if it has a second core just
to serve interrupts. In fact, some early architectures anticipated SMT
by having a second set of registers for privileged operation.
Or, since interrupt routines _are_ at kernel level... when there's an interrupt, save the whole internal machine state, including the entire pipeline. After all, since interrupt routines are privileged, they can
use a special return instruction that sets up the machine's internals
instead of just restoring registers and branching somewhere.
So, while interrupts _can_ be an issue for an OoO machine, they don't
really have to be.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 2026-10-23 7:57 p.m., John Savard wrote:

On Sat, 05 Oct 2024 17:57:12 GMT, [email protected]
(Anton Ertl) wrote:

Ok, it's more efficient to insert an interrupt call into the
instruction stream in the decoder: all the in-flight instructions will
be completed instead of going to waste. However, the interrupt will
usually be serviced later, and, as you point out, if the instruction
stream is redirected for some other reason, you may have to replay the
interrupt.

For Q+ one build option is similar to this. A poll-for-interrupt
instruction is periodically inserted into the instruction stream (approximately every 100 instructions) when micro-ops are translated and queued (could be the beginning of the decode stage). The poll operation
is a special form of branch and then handled by the branch logic.

The default Q+ build just has a hardware-interrupt flag on the pipeline registers, set at the fetch stage. When the pipeline reaches commit the
flag is checked and interrupt processing takes place if the flag was
set. Because it is a separate flag the processor knows to honor it even
if the instructions are no longer valid.

A _trap_ can be a problem on an out-of-order machine, since traps
result from exceptions, and so they have to be tied to the instruction stream.
An interrupt, on the other hand, just needs to get serviced. The
process being interrupted just needs not to be disturbed by it.
That leaves several alternatives.
You could somehow make the machine act as if it has a second core just
to serve interrupts. In fact, some early architectures anticipated SMT
by having a second set of registers for privileged operation.
Or, since interrupt routines _are_ at kernel level... when there's an interrupt, save the whole internal machine state, including the entire pipeline. After all, since interrupt routines are privileged, they can
use a special return instruction that sets up the machine's internals
instead of just restoring registers and branching somewhere.
So, while interrupts _can_ be an issue for an OoO machine, they don't
really have to be.

John Savard

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

[email protected] (John Savard) posted:

On Sat, 05 Oct 2024 17:57:12 GMT, [email protected]
(Anton Ertl) wrote:

Ok, it's more efficient to insert an interrupt call into the
instruction stream in the decoder: all the in-flight instructions will
be completed instead of going to waste. However, the interrupt will >usually be serviced later, and, as you point out, if the instruction
stream is redirected for some other reason, you may have to replay the >interrupt.

A _trap_ can be a problem on an out-of-order machine, since traps
result from exceptions, and so they have to be tied to the instruction stream.

We have {Traps, Exceptions, Interrupts}.

A trap is synchronous to the executing code and we want IP pointing at the subsequent instruction. A trap may send a small amount of data to the service at the other end. Not all registers have to be preserved. Registers R0..R15
are considered temporaries at the caller->callee boundary. Those registers either carry a result or are cleared <HW> at the callee->caller boundary::
in My 66000 SBI.

An Exception is synchronous to the executing code and we want IP pointing
at the offending instruction. What kind of exception is the message to the service routine. All Thread-State has to be preserved. A Thread should
be able to handle its own exceptions should it communicate same with
Guest OS.

An interrupt is asynchronous to the executing code and we can allow IP
to point at any instruction so long as a) all instructions prior to
*IP appear to have executed, and b) no instructions after *IP appear to
have executed. All Thread-State has to be preserved.

An interrupt, on the other hand, just needs to get serviced. The
process being interrupted just needs not to be disturbed by it.

Except via the time dimension...

That leaves several alternatives.
You could somehow make the machine act as if it has a second core just
to serve interrupts. In fact, some early architectures anticipated SMT
by having a second set of registers for privileged operation.

Or, since interrupt routines _are_ at kernel level... when there's an interrupt, save the whole internal machine state, including the entire pipeline. After all, since interrupt routines are privileged, they can
use a special return instruction that sets up the machine's internals
instead of just restoring registers and branching somewhere.

One now has to be careful, here. An interrupt can be taken in {HyperVisor,
Host OS, Guest OS, or even Application} although most architectures disallow the Application to field its own interrupts or exceptions and most definitely its own SYSCALLs.

Guest OS may receive a Page-Fault from Application and Guest OS has
arranged that its ISR pages are "not paged" and thus it is not setup
to deal with Guest OS Page-Faults in its own ISRs. Host OS can page
Guest OS pages out at its whim, and take Guest OS Page-Faults without
Guest OS ever knowing about those paging activities. So, virtualization
has added monkey-wrenches into the verbology ...

So, while interrupts _can_ be an issue for an OoO machine, they don't
really have to be.

Interrupts are easier than exceptions, mostly because one does not have to
back up the execution window.

John Savard

--- Synchronet 3.22a-Linux NewsLink 1.2