Re: Efficiency of in-order vs. OoO

Scott Lurndal wrote:

mitchalsup@aol.com (MitchAlsup1) writes:

Paul A. Clayton wrote:
>

On 2/26/24 10:48 AM, EricP wrote:

Paul A. Clayton wrote:

On 1/28/24 1:48 PM, EricP wrote:
[snip]

Multiple parallel pipelines is fine but it has to sequence the pipe exits
so the results retire in order for precise exceptions and interrupts.

>
In-order retire is not strictly required for precise exceptions
and certainly is not needed for interrupts. If the exception's
presence is determined before writeback of results from later
instructions, these writebacks can be prevented. One could
alternatively use a conservative filter of exception conditions
to stall writeback of later results (and stall those pipelines)
until it is known whether the exception occurs.

 Interrupts have to be restartable so in-order retire, where everything
older than the interrupt RIP is executed and retired and everything
after that RIP is not, is simplest and cheapest to implement.
Yes you could make it more complicated, but why?

>

The above described method still provides precise exceptions. The
absence of a earlier exception is required to allow such out-of-
order retirement.

>

This also means that handling of an asynchronous event might have
to be delayed (if one did not want to have two threads active)
until all instructions before the latest-in-program-order retired
instruction have retired.

>

For memory reads, the late failure generated by an uncorrectable
ECC error would probably have to be handled differently or there
would probably be little opportunity to exploit out-of-order
retirement. It might not be entirely unreasonable to treat such as
a fatal thread error that is asynchronous.

>
What about for memory stores where the ECC check on the delivered data fails ?? This seems to be just as fatal as a LD with an ECC fail.

As most stores are posted, the data stored needs to be 'poisoned'
so that any subsequent use of the data (e.g. a load) will report
a fault.

Storing the bad <arriving> ECC should take care of that.

The LLC (or memory controller) can optionally support an interrupt
to management software to indicate that an uncorrected fault occurred; that
would, of course, be asynchronous and occur long after the
store had retired.

I was going to check ECC on arrival at LLC and request retransmission
on failure. CPU sender cannot free the "miss buffer" until it gets a
release (arrived OK) from LLC. LLC then and later writes data into DRAM
through DRAM controller.