On Sat, Aug 14, 2010 at 9:43 AM, Gabe Black <gbl...@eecs.umich.edu> wrote:
>>>>
>>>>> @@ -889,11 +894,6 @@
>>>>> effAddrValid = true;
>>>>> fault = cpu->read(req, sreqLow, sreqHigh, data, lqIdx);
>>>>> } else {
>>>>> -
>>>>> - // Return a fixed value to keep simulation deterministic even
>>>>> - // along misspeculated paths.
>>>>> - data = (T)-1;
>>>>> -
>>>>> // Commit will have to clean up whatever happened. Set this
>>>>> // instruction as executed.
>>>>> this->setExecuted();
>>>>> @@ -901,7 +901,6 @@
>>>>>
>>>>> if (traceData) {
>>>>> traceData->setAddr(addr);
>>>>> - traceData->setData(data);
>>>>> }
>>>>>
>>>>> return fault;
>>>>>
>>>>>
>>>> So I see that you moved these lines up to read(), but if we ever call
>>>> readBytes() directly (not via read())---which I thought was why you
>>>> needed to add this---then shouldn't the equivalent functionality stay
>>>> down at this level?
>>>>
>>>>
>>> No. The data needs to be endian converted, and that doesn't make sense
>>> at readBytes.
>>>
>>
>> I can see where that applies for traceData->setData, but -1 is a
>> pretty endian-agnostic value. I'm just concerned that other call
>> sites for readBytes (which I assume are forthcoming) won't all
>> remember that these two things need to be done.
>>
>
> Oh, *that* part was what you were referring to. Yes, I wasn't quite sure
> what to do with that so I just got rid of it. I can easily believe that
> wasn't the right thing to do, so if you want me to put it back (or want
> to put it back yourself) I won't complain.
Actually I was originally referring to both parts; your explanation
made sense for one part but not the other. I'd be happy to have you
address the issue :-).
Steve
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
