The other portion of this, is when I try to make them act like loads, but not 
actually write a register I break the o3 cpu in ways that 4 hours has not been 
able to explain.

Ali

On Oct 26, 2010, at 10:42 PM, Ali Saidi wrote:

> The count gets smaller because since they don't actually access memory, they 
> never complete and therefore they never increment the instruction count.
> 
> Ali
> 
> On Oct 26, 2010, at 9:53 PM, Steve Reinhardt wrote:
> 
>> I vote for updating the stats... it's really wrong that we ignored them 
>> previously.
>> 
>> On Tue, Oct 26, 2010 at 5:47 PM, Ali Saidi <[email protected]> wrote:
>> Ok. So next question. With the CPU model treating prefetches as normal 
>> memory instructions the # of instructions changes for the timing simple cpu 
>> because the inst count stat is incremented in completeAccess(). So, one 
>> option is to update the stats to reflect the new count. The other option 
>> would be to stop marking the prefetch instructions as memory ops in which 
>> case they would just execute as nop. Any thoughts?
>> 
>> Ali
>> 
>> 
>> 
>> 
>> 
>> On Oct 24, 2010, at 12:14 AM, Steve Reinhardt wrote:
>> 
>>> No, we've lived with Alpha prefetches the way they are for long enough
>>> now I don't see where fixing them buys us that much.
>>> 
>>> Steve
>>> 
>>> On Sat, Oct 23, 2010 at 6:13 PM, Ali Saidi <[email protected]> wrote:
>>>> Sounds goo to me. I'll take a look at what I need to do to implement it.  
>>>> Any arguments with the Alpha prefetch instructions staying nops?
>>>> 
>>>> Ali
>>>> 
>>>> On Oct 22, 2010, at 6:52 AM, Steve Reinhardt wrote:
>>>> 
>>>>> On Tue, Oct 19, 2010 at 11:14 PM, Ali Saidi <[email protected]> wrote:
>>>>>> 
>>>>>> I think the prefetch should be sent the the TLB unconditionally, and 
>>>>>> then if the prefetch faults the CPU should toss the instruction rather 
>>>>>> than the TLB returning no fault and the CPU i guess checking if the PA 
>>>>>> is set?
>>>>>> 
>>>>>> I agree that we should override the fault in the CPU. Are we violently 
>>>>>> agreeing?
>>>>> 
>>>>> OK, it's becoming a little clearer to me now.  I think we're agreeing
>>>>> that the TLB should be oblivious to whether an access is a prefetch or
>>>>> not, so that's a start.
>>>>> 
>>>>> The general picture I'd like to see is that once a prefetch returns
>>>>> from the TLB, the CPU does something like:
>>>>> 
>>>>> if (inst->fault == NoFault) {
>>>>>   access the cache
>>>>> } else if (inst->isPrefetch()) {
>>>>>   maybe set a flag if necessary
>>>>>   inst->fault = NoFault;
>>>>> }
>>>>> 
>>>>> ...so basically everywhere else down the pipeline where we check for
>>>>> faults we don't have to explicitly except prefetches from normal fault
>>>>> handling.
>>>>> 
>>>>> If there are points past this one where we really care to know if a
>>>>> prefetch accessed the cache or not, then maybe we need a flag to
>>>>> remember that (sort of a dynamic version of the NO_ACCESS static
>>>>> flag), but I don't know if that's really necessary or not.  Clearly if
>>>>> the cache access doesn't happen right there, then we can add the flag
>>>>> and use it later to decide whether to access the cache.
>>>>> 
>>>>> Anyway, this is the flavor I was going for... any issues with it?
>>>>> 
>>>>> Steve
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> _______________________________________________
>> m5-dev mailing list
>> [email protected]
>> http://m5sim.org/mailman/listinfo/m5-dev
>> 
>> _______________________________________________
>> m5-dev mailing list
>> [email protected]
>> http://m5sim.org/mailman/listinfo/m5-dev
> 
> _______________________________________________
> m5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/m5-dev
> 

_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev

Reply via email to