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

Reply via email to