Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #118850

Re: Interrupts in OoO

Show all headers | View raw

On 2026-Oct-26 13:17, Robert Finch wrote:
> On 2026-10-26 11:06 a.m., EricP wrote:
>> On 2026-Oct-25 11:53, Scott Lurndal wrote:
>>> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>>>> quadibloc@invalid.com (John Savard) posted:
>>>>
>>>>> On Sat, 05 Oct 2024 17:57:12 GMT, anton@mips.complang.tuwien.ac.at
>>>>> (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.
>>>
>>> Exceptions are not alway precise.  For example, an exception
>>> on a posted store (that's spent time in a store buffer, for
>>> example), may have an exception asynchronously.
>>
>> This is a terminology problem that comes from processors putting
>> all the "alert" notifications through the same delivery mechanism.
>> People often use various the terms as interchangeable when really
>> they are not.
>>
>> In my terminology I have Exceptions, Interrupts, and Errors.
>> I take all the well defined stuff and put it in the Exception and
>> Interrupt buckets, and take all the weird stuff and call it Errors.
>>
>> Exceptions are defined by the ISA, are precise, and synchronous
>> to the excepting instruction. There are two kinds, Faults and Traps.
>> Most exceptions notifications cannot be deferred or "masked".
>> Floating point exceptions are potentially maskable however if
>> they are then any auxiliary information about the precise source of
>> the FP exceptions will be synchronous with instruction that unmasks
>> a pending floating point exception.
>>
>> Interrupts are defined as precise and asynchronous.
>> Their number and priority mechanisms is defined as model specific.
>> Interrupts are potentially maskable and may be deferred.
>> The only ISA defined part of interrupts are the master interrupt
>> mask control instructions INTEN enable and INTDI disable.
>>
>> Exceptions and Interrupts are defined as precise and restartable.
>>
>> The mechanism for delivering Exception and Interrupt notifications
>> is defined as model specific. In practice this just means that
>> operating systems should modularize this layer of their software
>> (sometimes called a HAL or Hardware Abstraction Layer).
>>
>> Errors are model and error specific, may be synchronous or asynchronous,
>> may be precise (Faults or Traps) or imprecise (Aborts).
>> Errors may or may not be deferred (maskable).
>> Errors may not be restartable.
>> The mechanism for delivering Error notifications is defined as
>> model and error specific.
>>
> I have thought that interrupts, traps and others are subsets of exceptions, which I think is the way m68k docs describes them. So, I would have errors as a subset of exceptions.
> 
> Interrupts, traps, errors and exceptions are all often handled by the same table which different vendors seem to give different names to.
> 
> I think interrupts may only be precise to a point. An interrupt is asynchronous, so how precise is it? In q+ the hardware may defer it to a short time later.

Precise means the processor state corresponds with a sequential model
of program execution where one instruction completes before the next begin.

Synchronous means that the saved state corresponds with the particular
instruction that triggered the state or the instruction after it.
For a Fault the state correspond to the triggering instruction.
For a Trap the state corresponds to the instruction after the
triggering instruction.
All exceptions, whether faults or traps, are synchronous.

Asynchronous means that the state does not correspond with any
particular instruction. All Interrupts are asynchronous.

For an asynchronous Interrupt or synchronous Exception to be
restartable it must be precise.

Each of Exceptions and Interrupts have well defined behaviour.
Exceptions only have one delivery mechanism whereas Interrupts might
have a variety of Interrupt controllers each with its own behavior.

They can also be quite frequent and I didn't want to burden their
dispatching mechanisms with the extra overhead of also dealing with
potential errors that might infrequently occur.
In both cases I would use a variation on branch-and-link to a hardware
state save and generated RIP address so there are no memory references
during the internal state change. This means no double- or triple-faults
and potentially a 1 clock state change.

The problem with errors is that their behaviour is all over the place.
A store operation to memory or device marked as write-through would be
synchronous with the ST instruction and any errors detected could be
associated back to the ST instruction.
A store operation to memory marked as write-back is asynchronous and
can be performed long after the ST instruction has retired and
been removed from the core.

An ECC memory error can be detected and maybe corrected by the
error scavenger sweep and not associated with any instruction at all.

Some devices change state when read. For example a UART receive
buffer can be FIFO queue and reading it consumes the first entry.
If there was a bus parity error after a successful read of the
FIFO then one may or may not want to retry the operation.

By putting infrequent Errors off in their own bucket they can be
dealt with on a case by case basis without burdening the frequent
occurance delivery mechanisms for Exceptions and Interrupts.

Back to comp.arch | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: Interrupts in OoO (was: Microarchitectural support for counting) quadibloc@invalid.com (John Savard) - 2026-10-23 23:57 +0000
  Re: Interrupts in OoO Robert Finch <robfi680@gmail.com> - 2026-10-23 21:12 -0400
  Re: Interrupts in OoO (was: Microarchitectural support for counting) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-24 19:20 +0000
    Re: Interrupts in OoO (was: Microarchitectural support for counting) scott@slp53.sl.home (Scott Lurndal) - 2026-10-25 15:53 +0000
      Re: Interrupts in OoO EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-26 11:06 -0400
        Re: Interrupts in OoO Robert Finch <robfi680@gmail.com> - 2026-10-26 13:17 -0400
          Re: Interrupts in OoO EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-26 17:03 -0400
            Re: Interrupts in OoO "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 14:14 -0700
              Re: Interrupts in OoO EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-28 14:39 -0400
                Re: Interrupts in OoO "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-28 15:10 -0700
                Re: Interrupts in OoO EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-29 14:50 -0400
            Re: Interrupts in OoO MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-27 16:48 +0000
        Re: Interrupts in OoO MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-27 16:35 +0000
          Re: Interrupts in OoO scott@slp53.sl.home (Scott Lurndal) - 2026-10-27 18:33 +0000
            Re: Interrupts in OoO MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-27 21:07 +0000
              Re: Interrupts in OoO scott@slp53.sl.home (Scott Lurndal) - 2026-10-27 21:17 +0000
                Re: Interrupts in OoO MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-28 15:35 +0000
                Re: Interrupts in OoO George Neuner <gneuner2@comcast.net> - 2026-10-28 14:34 -0400
                Re: Interrupts in OoO scott@slp53.sl.home (Scott Lurndal) - 2026-10-28 20:16 +0000
                Re: Interrupts in OoO MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-29 02:17 +0000
                Re: Interrupts in OoO "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-28 21:21 -0700
                Re: Interrupts in OoO George Neuner <gneuner2@comcast.net> - 2026-10-29 21:49 -0400
              Re: Interrupts in OoO EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-28 14:57 -0400
                Re: Interrupts in OoO MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-29 02:27 +0000
          Re: Interrupts in OoO EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-28 14:19 -0400
            Re: Interrupts in OoO MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-28 19:02 +0000
  Re: Interrupts in OoO (was: Microarchitectural support for counting) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-26 17:45 +0000
    Re: Interrupts in OoO (was: Microarchitectural support for counting) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-27 16:39 +0000

csiph-web