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

[E. Weddington]

> Hi,
> 
> On Mon, Jun 16, 2003 at 03:44:35PM +0000, E. Weddington 
wrote:
> > Originally, the inline assembly had not been marked 
> > volatile. However, I had gotten a bug report stating 
that 
> > the GCC optimizer had rearranged the inline assembly to 
the 
> > point where it wasn't working as defined. The fix was 
to 
> > mark all the inline assembly macros as volatile so the 
> > optimizer will leave them alone and have them work as 
> > defined. It would be great if you have a better 
solution 
> > that would work under all levels of optimization.
> 
> I've just looked at the current <avr/pgmspace.h> and I 
can see some
> bugs - possibly hidden by using "volatile"...
> 
> __LPM_enhanced__ should use "lpm %0,Z" (not Z+).

This was added because of a request to add other macros to 
allow further contiguous reads of flash without having to 
provide the address. I knew that this was only going to be 
available for the enhanced cores. I wrote an RFC to this 
list, with little response: 
<http://mail.nongnu.org/archive/html/avr-libc-dev/2003-
06/msg00002.html>
However, I haven't implmented this yet. If you feel that 
they shouldn't be implmented, let me know. I am not 
attached to it either way.


> __LPM_word_classic__ and __LPM_word_enhanced__ should 
tell GCC that
> they change r31:r30, by using a dummy output operand.
> 
> I think the "asm" should look like this ("volatile" not 
needed):
> 
>     __asm__ (
>       "lpm %A0, Z+" "\n\t"
>       "lpm %B0, Z+"
>       : "=r" (__result), "=z" (__addr16)
>       : "1" (__addr16)
>     );
> 
>  - operand 0: result, "=r" means "output in any general 
register"
>  - operand 1: incrememted pointer, "=z" means "output in 
r31:r30"
>  - operand 2: pointer, "1" means "input in the same 
register as operand 1"
> 
> The incremented pointer could be discarded, or used for 
the next LPM.

Again, these were for the additional macros describe above.

 
> There may well be real GCC optimizer bugs, too.  But, in 
this case
> I suspect the problem was with the "asm" not telling GCC 
the truth
> which registers are changed.
> 
> Yes, GCC asm is tricky and gives you enough rope to shoot 
yourself :)

Tell me about it! :)
 
> Hope this helps,
> Marek


Yes, this does help. Thanks for looking this over, I'll 
implement the changes you describe. Let me know what you 
think about the Z+ issue though.

Eric