Nigel Winterbottom wrote:
Watch out. Registers (r18-r27, r30-r31) ARE trashable by any function.
Because you call "bootloader_eeprom_read_byte", that too is allowed to
trash these registers. You cannot use (r18-r27, r30-r31) for variables
which "live" across a function call, unless of course you "push/pop" around
that function call.
That's true, but the compiler could use the high registers and save them
with the same or slightly more push/pops around the called functions,
and gain the ability to use the various instructions that only operate
on high registers. Perhaps that's too large of a scale of optimization
though, as it depends on number and position of calls, and overall
register usage (e.g. some of the function-clobbered registers are only
needed *before* the calls, etc.).
Incorrect. Only Y (r28/r29) is saved.
No, I said "caller", not "called". r28/r29 are the only registers that
the "called" function are required to save (of the top 4 pairs).
Try this macro:
#define HILOTO16(hi, lo) ({ \
unsigned int __result; \
__asm__ ( " mov %B0,%1 \n" : "=r" (__result) : "r" (hi), "0" (lo) ); \
__result; })
e.g. w = HILOTO16(c, b);
This gives optimal code and should cause a different compiler to complain,
> thereby highlighting the non portability.
Yeah, I can do that kind of stuff, but it's not really the point.
Merging bytes into a word is one of quite a number of common programming
idioms (esp. embedded) that I've seen gcc make hash of, so I want to see
if there's a way to peephole match more of them and inject better code.
_______________________________________________
AVR-GCC-list mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
