Re: MM instruction and the pipeline

On Tue, 22 Oct 2024 17:08:38 +0000, EricP wrote:

MitchAlsup1 wrote:

On Sun, 20 Oct 2024 15:57:59 +0000, Paul A. Clayton wrote:
>

With source-signaled errors, MM might be used to scrub memory
(assuming the microarchitecture did not optimize out copies
onto self as nops☺).
>
Not signaling the error until the destination is read some time
later prevents software from assuming the copy was correct at the
time of copying, but allows a copy to commit once all permissions
have been verified.

>
The real question, here, is: if you have corrupted data in memory
and overwrite it, in its entirety, do you have to detect the error ??
should you detect the error, or should overwriting the error make
it "go away" ???

>
IF an error is detected then it should be required to at least be
logged. But that particular error, no it should not be required to
be detected as that would force an extra read cycle onto every
quadword store.

This, too, is my interpretation--in a similar way that one can use
bad-ECC to denote uninitialized data which "goes away" when the
data gets written, Memory Moving good-data over bad-data makes
the error "go away".

>
By logging I mean a fifo buffer that error reports can be dumped into.

As I specified, all data errors are available at execute time
and can be properly trapped with precision.

This ensures that the fact an error was detected is not lost.
This can be set to trigger a high priority interrupt on a number of
conditions such as fifo buffer 3/4 full, or specific kinds of errors,
or when a log has been in the buffer a while, say 1 sec.
>
Also that error should not raise an error exception in an application
for any number of reasons, such as most writes are lazy and could be
long after the app that did the store has been switched out.

In My 66000 all written data is available prior to retirement, and
can be detected/corrected before the store is retired.

But each error must be assessed on an individual basis.