Re: Efficiency of in-order vs. OoO

Liste des GroupesRevenir à c arch 
Sujet : Re: Efficiency of in-order vs. OoO
De : paaronclayton (at) *nospam* gmail.com (Paul A. Clayton)
Groupes : comp.arch
Date : 25. Mar 2024, 03:46:18
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <utql1c$mvg6$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.0
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.

Date Sujet#  Auteur
24 Mar 24 * Re: Efficiency of in-order vs. OoO15Paul A. Clayton
24 Mar 24 `* Re: Efficiency of in-order vs. OoO14MitchAlsup1
25 Mar 24  `* Re: Efficiency of in-order vs. OoO13Paul A. Clayton
25 Mar 24   +- Re: Efficiency of in-order vs. OoO1Anton Ertl
25 Mar 24   +- Re: Efficiency of in-order vs. OoO1MitchAlsup1
25 Mar 24   `* Re: Efficiency of in-order vs. OoO10Anton Ertl
25 Mar 24    +- Re: Efficiency of in-order vs. OoO1BGB
25 Mar 24    +* Re: Efficiency of in-order vs. OoO6John Dallman
26 Mar 24    i+- Re: Efficiency of in-order vs. OoO1Anton Ertl
26 Mar 24    i`* Re: Efficiency of in-order vs. OoO4Anton Ertl
26 Mar 24    i `* Performance monitoring (was: Efficiency of in-order vs. OoO)3Anton Ertl
26 Mar 24    i  +- Re: Performance monitoring (was: Efficiency of in-order vs. OoO)1John Dallman
26 Mar 24    i  `- Re: Performance monitoring1MitchAlsup1
25 Mar 24    `* Re: Efficiency of in-order vs. OoO2Terje Mathisen
26 Mar 24     `- Re: Efficiency of in-order vs. OoO1Terje Mathisen

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal