[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] volatile in pgmspace.h ?
From: |
E. Weddington |
Subject: |
Re: [avr-libc-dev] volatile in pgmspace.h ? |
Date: |
Mon, 16 Jun 2003 20:53:50 GMT |
> 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
- [avr-libc-dev] volatile in pgmspace.h ?, Dmitry K., 2003/06/14
- Re: [avr-libc-dev] volatile in pgmspace.h ?, E. Weddington, 2003/06/16
- Re: [avr-libc-dev] volatile in pgmspace.h ?,
E. Weddington <=
- Re: [avr-libc-dev] volatile in pgmspace.h ?, Unknown, 2003/06/16
- Re: [avr-libc-dev] volatile in pgmspace.h ?, E. Weddington, 2003/06/16
- Re: [avr-libc-dev] volatile in pgmspace.h ?, E. Weddington, 2003/06/17
- Re: [avr-libc-dev] volatile in pgmspace.h ?, E. Weddington, 2003/06/17
- Re: [avr-libc-dev] volatile in pgmspace.h ?, E. Weddington, 2003/06/17
- Re: [avr-libc-dev] volatile in pgmspace.h ?, E. Weddington, 2003/06/17