Hey Eliot,
thank you for your answer. I have a follow-up question.
I know, that there are more physical registers than architectural ones and that the achitectural state should be set in the final commit state.
So if the debug message linked in my earlier mail shows e.g.: "Setting int register 54 to 0x53000", this "register 54" should be a physical register and it can be used without setting the architectural state?
So if the debug message linked in my earlier mail shows e.g.: "Setting int register 54 to 0x53000", this "register 54" should be a physical register and it can be used without setting the architectural state?
Do you know, at which point in the O3 steps this physical register is set after an instruction?
Kind regards
Gesendet: Mittwoch, 14. Februar 2024 um 17:47 Uhr
Von: "Eliot Moss" <m...@cs.umass.edu>
An: "The gem5 Users mailing list" <gem5-users@gem5.org>
Cc: reverent.gr...@web.de
Betreff: Re: [gem5-users] Architectural state of registers - O3CPU
Von: "Eliot Moss" <m...@cs.umass.edu>
An: "The gem5 Users mailing list" <gem5-users@gem5.org>
Cc: reverent.gr...@web.de
Betreff: Re: [gem5-users] Architectural state of registers - O3CPU
On 2/14/2024 11:19 AM, reverent.green--- via gem5-users wrote:
> Hello everyone,
> can someone give me a hint, where exactly in the code the architectural state of (load) instructions is getting set and
> becomes visible? I tried to trace instructions during the execution via log outputs, but got a bit lost during the IEW
> stage.
> I know, that instructions, which depend on specific registers will wait until the register is marked ready from an
> earlier usage. (https://github.com/gem5/gem5/blob/stable/src/cpu/o3/regfile.hh#L273)
> But is this already equivalent to the architectural state?
>
> And how is this handled during a wrong speculative execution because of the following rollback/squashing?
> Kind regards
> Robin
A typical out-of-order processor does register renaming, so there are
generally *many* more physical registers than architectural ones, and the
hardware maintains a dynamic mapping. If necessary, the architectural state
can be constructed, but generally would not be unless you're switching threads
or something. While IEW may update the registers (I believe), it is the
commit stage that makes the change "permanent".
Does that help?
Eliot Moss
> Hello everyone,
> can someone give me a hint, where exactly in the code the architectural state of (load) instructions is getting set and
> becomes visible? I tried to trace instructions during the execution via log outputs, but got a bit lost during the IEW
> stage.
> I know, that instructions, which depend on specific registers will wait until the register is marked ready from an
> earlier usage. (https://github.com/gem5/gem5/blob/stable/src/cpu/o3/regfile.hh#L273)
> But is this already equivalent to the architectural state?
>
> And how is this handled during a wrong speculative execution because of the following rollback/squashing?
> Kind regards
> Robin
A typical out-of-order processor does register renaming, so there are
generally *many* more physical registers than architectural ones, and the
hardware maintains a dynamic mapping. If necessary, the architectural state
can be constructed, but generally would not be unless you're switching threads
or something. While IEW may update the registers (I believe), it is the
commit stage that makes the change "permanent".
Does that help?
Eliot Moss
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
