[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
why gets "invalidate_cache" a const void ptr?
- Date: Fri, 9 Apr 2010 12:53:04 -0500
- From: joel.sherrill at OARcorp.com (Joel Sherrill)
- Subject: why gets "invalidate_cache" a const void ptr?
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:
>> 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
>> 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
> 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.
>> what do you all think?
>> I would vote to remove the "const" keyword in the declaration and the
>> implementations of the functions.
>> 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
> rtems-users mailing list
> rtems-users at rtems.org
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