Haase Bjoern (PT/EMM1) schreef:
Yes I will try to put together a patch with the minimal changes. I only
need
to know one thing; can I assume that using this construction:
/** \ingroup avr_eeprom
Read one 16-bit word (little endian) from EEPROM address \c addr.
*/
uint16_t
eeprom_read_word (const uint16_t *addr)
{
register uint16_t result asm("r24"); //I can specify r24 only
__asm__ __volatile__ (
XCALL " __eeprom_read_word_" _REG_LOCATION_SUFFIX CR_TAB
: "+x" (addr),
"=w" (result) //Use w restrict to adiw capable registers
: );
return result;
}
I fear that this will not be guaranteed to be correct! The compiler
might reorder code and might be tempted to optimize away your result
variable so that it could be placed in another register. The dangerous
thing is, that your code might work sometimes!
I found even more "prove":
http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Extended-Asm.html#Extended-Asm
"Sometimes you need to make an asm operand be a specific register, but
there's no matching constraint letter for that register by itself. To
force the operand into that register, use a local variable for the
operand and specify the register in the variable declaration. See
Explicit Reg Vars. Then for the asm operand, use any register constraint
letter that matches the register:
register int *p1 asm ("r0") = ...;
register int *p2 asm ("r1") = ...;
register int *result asm ("r0");
asm ("sysint" : "=r" (result) : "0" (p1), "r" (p2));"
So I think it's perfectly legal to do what I wanted to do.
I checked the documentation, this feature is documented back to at least
2.9.5. Did AVR even existed in GCC back then? If not it will not causes
a problem for users building avr-libc with an older version of GCC
The 2.9.5 documentation:
http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC96
HTH,
Wouter
_______________________________________________
AVR-libc-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
