Quoting nathan binkert :
>> initiateAcc looks something like the following:
>>
>> Fault initiateAcc(..., traceData,...)
>> {
>>...
>>write(); <<< traceData becomes invalid in here
>>if (traceData) traceData->setData(Mem);
>>...
>> }
>>
>> so I'm not sure how that would work.
>
> Wh
> initiateAcc looks something like the following:
>
> Fault initiateAcc(..., traceData,...)
> {
> ...
> write(); <<< traceData becomes invalid in here
> if (traceData) traceData->setData(Mem);
> ...
> }
>
> so I'm not sure how that would work.
Why is traceData passed in as a parameter
initiateAcc looks something like the following:
Fault initiateAcc(..., traceData,...)
{
...
write(); <<< traceData becomes invalid in here
if (traceData) traceData->setData(Mem);
...
}
so I'm not sure how that would work.
Gabe
Quoting nathan binkert :
>> 7. initiateAcc uses
> 7. initiateAcc uses its local (and now invalid) copy of the traceData
> pointer to store the result of the instruction executing.
What if you just read this pointer again and not store a local copy?
Nate
___
m5-dev mailing list
m5-dev@m5sim.org
http
Here is a hypothetical series of events that should hopefully
illustrate what's going on.
1. The store conditional comes up for execution and its initiateAcc is called.
2. initiateAcc calls xc->write() to actually do the required store.
3. write calls into the TLB's translateTiming function to d
Hi Gabe,
I'm trying to figure out what's going and help find a potentially better
solution (if there is one), since I'm operating under the assumption that
adding a small overhead for the common case memory access to support the
special case (stl_c) should be avoided if possible. (SIDEBAR: In looki
See /z/m5/regression/regress-2009-04-27-03:00:01 for details.
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
