Path: ...!feeds.phibee-telecom.net!weretis.net!feeder6.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Efficiency of in-order vs. OoO
Date: Sun, 10 Mar 2024 19:39:21 +0000
Organization: Rocksolid Light
Message-ID: <24958d8cc6a4fb16cda65fc4f50efe34@www.novabbs.org>
References: <uigus7$1pteb$1@dont-email.me> <unbumf$lot2$1@dont-email.me> <uncbrq$o1ml$1@dont-email.me> <06c802c7848a4a522bc022bbd2fdce68@news.novabbs.com> <2024Jan7.091347@mips.complang.tuwien.ac.at> <uoovaf$1crob$1@dont-email.me> <2024Jan24.084731@mips.complang.tuwien.ac.at> <uorlft$1ti8a$1@dont-email.me> <2024Jan24.225412@mips.complang.tuwien.ac.at> <cslsN.381334$83n7.291175@fx18.iad> <2024Jan25.074631@mips.complang.tuwien.ac.at> <nCtsN.64363$Sf59.39184@fx48.iad> <2024Jan25.162230@mips.complang.tuwien.ac.at> <jWPsN.286143$c3Ea.55679@fx10.iad> <a292b7f4fd21a329c25a686bb16a2b4d@www.novabbs.org> <gkxtN.44654$SyNd.35025@fx33.iad> <urg470$215g3$3@dont-email.me> <zp2DN.467627$xHn7.106497@fx14.iad> <usgid7$20vho$1@dont-email.me> <2nlHN.65668$mMj7.39270@fx01.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="1543987"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="PGd4t4cXnWwgUWG9VtTiCsm47oOWbHLcTr4rYoM0Edo";
User-Agent: Rocksolid Light
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$wvzwu757EFu531ARyvfgGeKpjFsTNQ0C/ocQJtUVlpsF1sSf24h8q
Bytes: 4068
Lines: 55

EricP wrote:

> 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]
>> The above described method still provides precise exceptions. The
>> absence of a earlier exception is required to allow such out-of-
>> order retirement.

> Yes, early OoO retire with precise exception is possible.
> The criteria would seem to be that:
> - all older instructions that might generate an exception must have
>    executed without detecting an exception
> - plus all older loads and stores translated their virtual addresses
>    (loads don't need to have completed execution, and stores will not have)
> - plus all older conditional branches have executed without mispredicting.
 You missed
  - all inbound cache lines need to have arrived without ECC errors.

> My concern is that the circuit for doing this could be pretty complicated.

Essentially equal in complexity to an IO retirement µArchitecture.

> Many of the pieces that have to be checked are scattered around the core.
> Also many of states are in circular buffers so determining "older" starts
> getting slightly hairy (the Load Store Queue has a similar problem for
> disambiguation determining if all older loads and stores have "resolved").
> And all this has to run in parallel so it takes less than 1 clock.

> The motivation for early OoO retire is usually early recycling of some
> resources, usually physical registers. However note that you can't early
> recycle some resources like entries in circular buffers, such as the
> Instruction Queue, ROB/Future-File, LSQ, Branch Queue.

> So the question I have is it really worth it?

History says no.

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

Which is exactly the IO retire criterion. Why go OoO retire when you have
to be able to IO retire under certain circumstances ?!?

<snip>

> I define errors as a whole different category from exceptions and
> interrupts, and explicitly model dependent, and each error has its
> own characteristics.

Errors are different--machine checks, for example. These things SHOULD 
not happen and you really do want to know if they do.