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

Groups > comp.arch > #118869

Re: Interrupts in OoO

Show all headers | View raw

EricP <ThatWouldBeTelling@thevillage.com> posted:

> 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.

To a very large extent I agree with you. The things you call errors
I call Checks. Checks are never supposed to happen {{like late store
data ECC fails}}.
 
> 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).

It is at this point I generally point out that Checks {errors} deliver
control to the highest privilege level {HyperVisor} not the next higher
privilege level {Guest OS when in User}.

> Errors may not be restartable.
> The mechanism for delivering Error notifications is defined as
> model and error specific.

No, while the checks are model specific, the mechanism to deliver them
to HV is specified.
> 

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