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 was afraid so, but I look it up in the GCC documentation
http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Local-Reg-Vars.html#Local-Reg-Vars
"This option does not guarantee that GCC will generate code that has
this variable in the register you specify at all times. You may not code
an explicit reference to this register in the assembler instruction
template part of an asm statement and assume it will always refer to
this variable. However, using the variable as an asm operand guarantees
that the specified register is used for the operand."
Also on:
http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Explicit-Reg-Vars.html#Explicit-Reg-Vars
" These local variables are sometimes convenient for use with the
extended asm feature (see Extended Asm), if you want to write one output
of the assembler instruction directly into a particular register. (This
will work provided the register you specify fits the constraints
specified for that operand in the asm.)"
So it seems to me that it used as it was intended. So I think it's legal
after all.
HTH,
Wouter
_______________________________________________
AVR-libc-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
