On Sat, Aug 14, 2010 at 9:43 AM, Gabe Black <[email protected]> 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 [email protected] http://m5sim.org/mailman/listinfo/m5-dev
