Path: ...!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Paul A. Clayton" <paaronclayton@gmail.com>
Newsgroups: comp.arch
Subject: Re: Efficiency of in-order vs. OoO
Date: Sun, 24 Mar 2024 21:46:18 -0400
Organization: A noiseless patient Spider
Lines: 38
Message-ID: <utql1c$mvg6$1@dont-email.me>
References: <uigus7$1pteb$1@dont-email.me>
 <801cec7a5387e0c867430275486171f7@news.novabbs.com>
 <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> <urg471$215g3$7@dont-email.me>
 <87e39cb1345cb3575c49196f3ee56cee@www.novabbs.org>
 <utpkun$fdrm$1@dont-email.me>
 <d28278800443aa5f710d20d03a54ff78@www.novabbs.org>
 <Wb0MN.450377$yEgf.117969@fx09.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 25 Mar 2024 02:46:21 +0100
Injection-Info: dont-email.me; posting-host="fff16760133a2019739dcfb547ded9d1";
	logging-data="753158"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18FldpG5xQGF5UQKGfoaWuITeC7JGolBnM="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.0
Cancel-Lock: sha1:t8PQhqAlAB0jTd3o/XOzK4JIfQ8=
In-Reply-To: <Wb0MN.450377$yEgf.117969@fx09.iad>
Bytes: 3416

On 3/24/24 4:39 PM, Scott Lurndal wrote:
> mitchalsup@aol.com (MitchAlsup1) writes:
>> Paul A. Clayton wrote:
> 
>>> (I was also very surprised by how much extra state the A55 has:
>>> over 100 extra "registers". Even though these are not all 64-bit
>>> data storage units, this was still a surprising amount of extra
>>> state for a core targeting area efficiency. The storage itself may
>>> not be particularly expensive, but it gives some insight into how
>>> complex even a "simple" implementation can be.)
>>
>> Imaging having to stick all this stuff on a die at 2µ instead of 5nm !!
> 
> I suspect Paul is refering to what ARMv8 calls "System Registers";

Yes. (There were also some debug registers, performance monitoring
registers, trace registers, etc.)

> despite the name, most are stored in flops, and in the case of
> the ID registers, wires (perhaps anded with local e-fuses).

Yes, many of the bits would be implemented as ROM/PROM and many
would presumably be scattered about because they control/interact
with specific functionality. They are similar I/O device
registers. (I/O devices have also become more complex.)

However, having over 100 seems like a lot. Supporting performance
counters and tracing is also something that would have been nearly
inconceivable for something like the MIPS R2000.

An argument might be made that some designs would have no use for
most of such extra state. Performance monitoring is useful for
software development (and theoretically for OS decisions for
scheduling, core migration, and other functions), but seems likely
to be highly underutilized for typical use. A55 is presumably
large enough that a synthesis-time remove of much of this
functionality would have a tiny effect on total area. Even for a
microcontroller the area cost might not be problematic.