Re: [avr-gcc-list] "Volatile"

[David Brown]

> David Brown wrote:
>
> > ...  I cannot think of any sort of architecture ... that would
> > require read-modify-write to set a char to a constant value, since a
char
> is
> > always directly addressible (on machines that can't directly address an
> > 8-bit byte, a C "char" may be 16-bit or bigger).
>
> On a 32-bit machine (e.g. Freescale MPC8260) where the variable is mapped
to
> a 32-bit wide hardware register (e.g. Infineon "Purple" Ethernet switch)
> setting a char is not atomic.  The whole register must be read, one byte
> modified, and the result written back.  This is an extreme case but I'm
not
> convinced there wouldn't be more subtle ones that would make reliance on
> atomic char writes unportable.  (Getting rather OT here, sorry.)
>

I'm not convinced on that one.  There may well be hardware registers which
do not support byte (or 16-bit "half-word") access on the chip - I know
there are such peripherals on other 32-bit Freescale microcontrollers.  But
that has nothing to do with the cpu itself, nor the code generated by
compilers.  If you write code to store a byte of data in the 32-bit
register, then the compiler will generate a single byte store instruction
(preceeded by instructions to load a register with the immediate data, as
required by a RISC cpu like the ppc), and that byte store will be executed
atomicly.  Just because it won't work as expected due to hardware
considerations, doesn't make it non-atomic.  If you really want to change
one byte in this 32-bit access only register, you have to write C code
yourself to do the manipulation, and thus have moved from the simple direct
C code that generates a single cpu instruction.

Note that the assignment is atomic even if the assembly consists of more
than one instruction (e.g., something like ldi r16, #1; st r16, flag ).  The
point of an "atomic" access is that there is no way to break the statement
into a "half-done" step, as viewed by interrupt functions or external
accesses of some sort.  Even if an interrupt occured between these two
instructions, the flag change itself would not be affected - thus it is
atomic.


> and David Brown also wrote:
>
> > I have worked with gcc ports where "volatile" was used to indicate
> > that a variable should bypass cache, *in addition to* the standard
> > properties of volatile.
>
> Wow.  This is new to me.  Thanks for this.
>
> and finally David Brown wrote:
>
> > There is nothing in the C standard that restricts adding
> > additional properties like this to volatile ...
>
> I will take your word for it, but is this really a good idea?  If you were
> defining the Altera Nios language extensions, would you overload volatile
> with the cache bypass effect or would you add a new qualifier, such as
> uncached, to do this?
>
> Graham.
>

I think the use of volatile like this is a good idea.  Can you think of a
situation where you would want cached volatile data?  Making volatile access
uncached might not be required by the letter of the C standard, but it
certainly follows all sensible uses of volatile.  It is still perfectly
possible to access data as uncached yet not volatile (by fiddling the msb) -
IIRC there were even library functions for allocating uncached memory blocks
that first allocated a real memory block, then returned a pointer with the
msb set.