I would like to add some additional information. The register number does vary in each iteration, sometimes it is above 100. So I think it should be the physical register value.
If my understanding is correct, the physical register should be set during the IEW stage before the instruction is commited or squashed at the last stage. Otherwise out-of-order execution wouldn't be possible.
If my understanding is correct, the physical register should be set during the IEW stage before the instruction is commited or squashed at the last stage. Otherwise out-of-order execution wouldn't be possible.
So in the end I am searching the point at which the physical register is set and marked as ready for subsequent instruction, which depend on this specific register.
Gesendet: Mittwoch, 14. Februar 2024 um 18:35 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] Re: 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] Re: Architectural state of registers - O3CPU
On 2/14/2024 12:26 PM, reverent.green--- via gem5-users wrote:
> 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?
> Do you know, at which point in the O3 steps this physical register is set after an instruction?
That's something where I'd need to dig into the code the make sure. However,
the number 53 is fairly large so my first impression is that it is a physical
register number, not a logical (architectural) one. On the other hand, if you
count up integer registers, floating point registers, vector registers, etc.,
53 could be in the range of the architectural registers. I do know that if
you request debug trace information from gem5, it will tend to refer to
architectural registers.
I don't know precisely where the physical register is set, but my first
thought is IEW - the W part stands for Writeback, i.e., when registers
typically are written. However, loads are probably written later since they
are not computational but wait for a response from the cache. As I recall,
the load/store queue processing is a separate step in the pipeline, coming
later than IEW.
EM
> 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?
> Do you know, at which point in the O3 steps this physical register is set after an instruction?
That's something where I'd need to dig into the code the make sure. However,
the number 53 is fairly large so my first impression is that it is a physical
register number, not a logical (architectural) one. On the other hand, if you
count up integer registers, floating point registers, vector registers, etc.,
53 could be in the range of the architectural registers. I do know that if
you request debug trace information from gem5, it will tend to refer to
architectural registers.
I don't know precisely where the physical register is set, but my first
thought is IEW - the W part stands for Writeback, i.e., when registers
typically are written. However, loads are probably written later since they
are not computational but wait for a response from the cache. As I recall,
the load/store queue processing is a separate step in the pipeline, coming
later than IEW.
EM
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
