Re: [avr-libc-dev] volatile in pgmspace.h ?

[E. Weddington]

> On Tue, Jun 17, 2003 at 03:12:20PM +0000, E. Weddington 
wrote:
> > Unfortunately, that would assume that the argument to 
the 
> > macro would be a variable. If the argument is a 
constant, 
> > it wouldn't work.
> 
> Yes.  The _next macros would only work with a variable as 
the
> address, while the normal ones work with any expression.
> I don't see any problem here - pgm_read_byte_next
(address) would
> work just like pgm_read_byte(address++), except that you 
get the
> post-increment for free as part of the LPM instruction.  
Both
> kinds of macros (with and without post-increment) can be 
useful
> at various times.  With the "ELPM" versions of the _next 
macros,
> RAMPZ can be incremented too, so after the operation it 
should
> be stored in the third byte of the address.
> 
> Marek


Again, your comment about how it cannot be guaranteed that 
gcc will keep the value of Z in between calls to the macros 
is a strong argument against inclusion of _next() macros.

Certainly something like this:

val[0] = pgm_read_byte(address);
val[1] = pgm_read_byte_next(address);
val[2] = pgm_read_byte_next(address);
val[3] = pgm_read_byte_next(address);

would probably work as expected. However, if you start 
doing too much else, such as:

val[0] = pgm_read_byte(address);
for(i = 1; i < 16; i++)
{
    val[i] = pgm_read_byte_next(address);
    if(val[i] != 0)
    {
        // do something
    }
}

then you will probably run into problems as stated: it 
cannot be guaranteed that gcc will keep the value of Z in 
between calls.

.. of course it would be ideal if GCC knew something about 
Harvard architectures and could rationally deal with 
seperate address spaces... but that's a different matter.:)

Eric