why gets "invalidate_cache" a const void ptr?

Till Straumann strauman at slac.stanford.edu
Fri Apr 9 21:35:07 UTC 2010


Gedare Bloom wrote:
> On Fri, Apr 9, 2010 at 2:34 PM, Thomas Dörfler
> <Thomas.Doerfler at embedded-brains.de> wrote:
>   
>> Hi,
>>
>>     
>>>> I am having trouble seeing where this case would happen.  Why would
>>>> you have a system which cached some memory knowing that the
>>>> memory and cache would be inconsistent?
>>>>
>>>>         
>>> The sparc (and sparc64) port deals with this, when it registers a trap
>>> (interrupt) handler, it replaces the entry in the trap table going
>>> through the data cache, and needs to make sure to invalidate the
>>> instruction cache, because the instructions for the old handler might
>>> exist.
>>>
>>> -Gedare
>>>
>>>       
>> Right. And you pass a pointer to the "invalidate" function, it promises
>> you (through the "const" keyword) that it will NOT modify the passed in
>> object, but, at least from a CPU point of view, the memory area will
>> look different after the call.
>>
>> That is exactly what I find illogical/wrong.
>>
>>     
> I see your complaint: from the caller's point-of-view, the memory
> returned by accessing the pointer to const passed as an argument might
> be altered across the function call, although the memory itself didn't
> change, the cache was out-of-date.  However, the function does not
> actually write to the memory 
Not sure I agree with that.

A typical situation where you need to invalidate parts of the
data cache is when you have a device DMA stuff to memory
with hardware that doesn't support cache snooping.

Hence you explicit invalidate the cache so that the next
read operation fetches the DMAed data and not some stale
data from the cache.

Hence, from the perspective of the caller the function DID
change the memory.

I vote for removing the 'const' (and replace it with 'volatile').

BTW: all this is moot if the alias rule comes into play.


-- Till
> -- the memory was written before by
> something else, perhaps DMA or d/i cache mismatch.  I'm not sure
> whether it is better to elide the const modifier or not, but it does
> let the compiler ensure that the invalidate function does not attempt
> to write to the memory location, which is certainly what is expected.
> Is "volatile const void*" acceptable to the compiler and does that
> make any more sense?
>
> Any one have opinions?
> -Gedare
>   
>> Thomas.
>>
>>     
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>   




More information about the users mailing list