Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: MM instruction and the pipeline
Date: Tue, 22 Oct 2024 18:16:25 +0000
Organization: Rocksolid Light
Message-ID: <2d9efe6d94c7549e79723276e76da861@www.novabbs.org>
References: <venkii$23b6b$1@dont-email.me> <vep8rb$2d8ru$1@dont-email.me> <bf46a508f4e6bbe44846078a50af63b7@www.novabbs.org> <vf39a8$fr1q$1@dont-email.me> <aa58a1a08f09adf4539bcafef4e853d8@www.novabbs.org> <j%QRO.14206$tnK2.5850@fx04.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="3215036"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$X/akWqKW5Ffi8xYvatinZesfoJYV8Y7sLx6faz75iV6fHlqWoskO2
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
Bytes: 3185
Lines: 46

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.