Thank you Elliot and Ayaz for the well explained responses. I understood the code snippet now.
On Tue, Jul 11, 2023 at 5:46 PM Ayaz Akram <yazak...@ucdavis.edu> wrote: > Hi Eliot, > > Based on my understanding, when pkt->makeResponse() is called it updates > the "cmd" of the pkt with the appropriate responseCommand (this line of > code: cmd = cmd.responseCommand();) . If you look at > "MemCmd::commandInfo[]" in packet.cc, the response command for a > "WriteReq" command is "WriteResp". And the attributes of a "WriteResp" > command don't have "HasData", which is why the response pkt will return > false on a "hasData()" check. > > You might also want to look at the struct CommandInfo in packet.hh. > > -Ayaz > > On Tue, Jul 11, 2023 at 2:15 PM Eliot Moss via gem5-users < > gem5-users@gem5.org> wrote: > >> On 7/11/2023 3:03 PM, John Smith wrote: >> > Thanks for responding, Elliot. I somewhat understand that after the >> write is accomplished, the >> > returning packet won't have the data. But still, why is the returned >> value 0 in that case? Shouldn't >> > it still be equal to the memory access latency. >> >> In the Atomic case this code is assuming the write can >> be absorbed into a write buffer, so there is no additional >> latency visible to the user. Of course it is *possible* to >> saturate the buffers, and if you want a more accurate >> accounting you can use a Timing model instead. >> >> EM >> _______________________________________________ >> gem5-users mailing list -- gem5-users@gem5.org >> To unsubscribe send an email to gem5-users-le...@gem5.org >> >
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
