why gets "invalidate_cache" a const void ptr?

Joel Sherrill joel.sherrill at OARcorp.com
Fri Apr 9 17:53:04 UTC 2010


On 04/09/2010 12:43 PM, Gedare Bloom wrote:
> On Fri, Apr 9, 2010 at 1:05 PM, Thomas Dörfler
> <Thomas.Doerfler at embedded-brains.de>  wrote:
>    
>> Hi,
>>
>> I just tripped over a strange thing: the "*invalidate_*_cache" functions
>> in cpukit/rtems/rtems/include/rtems/cache.h are declared to get a "const
>> void *" pointer passed in. IMHO the "const" is wrong, because the
>> function may modify the storage where the pointer points to
>>
>>      
> Is there a case where this happens?
>    
I don't think the cache method is allowed to modify the contents.
It is simply flushing it from the CPU cache.  The underlying memory
is unchanged.
>    
>> Background:
>> 1.) when a cache line is invalidated, the real memory behind it may
>> become visible and have a different content than available in the cache
>> previously.
>>
>>      
> Yes, that is probably why the line was invalidated.
>
>    
I suppose this is possible if the cache is inconsistent with memory.
But wouldn't that make volatile more appropriate?

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?

>> 2.) Having that function to get a "const void *" allos GCC to use more
>> optimizations, which may result in wrong code.
>>
>>      
> Are there examples of gcc optimizations that act on pointer to const?
> Having const enforces code paths in the cache_invalidate family to not
> attempt to write-back data to the address, I think this is expected
> behavior when someone invalidates a cache line.
> -Gedare
>
>    
>> what do you all think?
>>
>> I would vote to remove the "const" keyword in the declaration and the
>> implementations of the functions.
>> wkr,
>> Thomas.
>>
>> --
>>
>> --------------------------------------------
>> Embedded Brains GmbH
>> Thomas Doerfler        Obere Lagerstrasse 30
>> D-82178 Puchheim       Germany
>> email: Thomas.Doerfler at embedded-brains.de
>> Phone: +49-89-18908079-2
>> Fax:   +49-89-18908079-9
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-users
>>
>>      
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>    


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985





More information about the users mailing list