[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Missing compiler optimizations?

From: Erik Walthinsen
Subject: Re: [avr-gcc-list] Missing compiler optimizations?
Date: Mon, 23 Jan 2006 11:47:08 -0800
User-agent: Debian Thunderbird 1.0.7 (X11/20051017)

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]