[gem5-users] Re: Architectural state of registers - O3CPU
On 2/14/2024 1:14 PM, Eliot Moss via gem5-users wrote: On 2/14/2024 12:52 PM, reverent.green--- via gem5-users wrote: 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. 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. Yes, it makes sense that it is a physical register. For arithmetic, register to register move, etc., it would be written in IEW. But for loads, it cannot be written until LSQ processing, which is later in the pipeline. I believe there is a notion of the register being *ready*, and it will be marked ready when it is written. Likewise, once all of an instruction's input registers are ready, that instruction may be executed (the instruction itself becomes ready). You can look for the 'writeback' function in lsq_unit.cc. It clearly has some relationship to IEW, but it explicitly calls completeAcc, which does the actual write into the register. The specific code for that came from the instruction's template. This is necessarily so - consider the difference between loading a byte (say) vs a word, and sign- vs zero-extended values. See also function writebackInsts in iew.cc. EM ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Re: Architectural state of registers - O3CPU
On 2/14/2024 12:52 PM, reverent.green--- via gem5-users wrote: 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. 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. Yes, it makes sense that it is a physical register. For arithmetic, register to register move, etc., it would be written in IEW. But for loads, it cannot be written until LSQ processing, which is later in the pipeline. I believe there is a notion of the register being *ready*, and it will be marked ready when it is written. Likewise, once all of an instruction's input registers are ready, that instruction may be executed (the instruction itself becomes ready). You can look for the 'writeback' function in lsq_unit.cc. It clearly has some relationship to IEW, but it explicitly calls completeAcc, which does the actual write into the register. The specific code for that came from the instruction's template. This is necessarily so - consider the difference between loading a byte (say) vs a word, and sign- vs zero-extended values. Regards - EM ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Re: Architectural state of registers - O3CPU
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. 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" An: "The gem5 Users mailing list" 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 ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[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 ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Re: Architectural state of registers - O3CPU
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? Kind regards Gesendet: Mittwoch, 14. Februar 2024 um 17:47 Uhr Von: "Eliot Moss" An: "The gem5 Users mailing list" 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 ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Re: 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 ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
