[Top][All Lists]

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

Re: [avr-gcc-list] Fixed, external function "pointers"

From: Erik Christiansen
Subject: Re: [avr-gcc-list] Fixed, external function "pointers"
Date: Fri, 13 Jan 2006 12:35:09 +1100
User-agent: Mutt/1.5.6+20040722i

On Thu, Jan 12, 2006 at 03:03:45PM -0800, Erik Walthinsen wrote:
> I'm completely unfamiliar with linker scripts, can I have a short linker 
> script that contains *just* the above information and tacks onto / 
> replaces the normal parameters just by listing it on the linker cmdline? 

Nope, AFAIK, you're doing the next best thing, on the command line.
(Next best, because things are spread around, rather than the linker
script defining the memory map entirely.)

>  Or do I have to snapshot the entire linker script from a given version 
> of ld and modify it slightly (and keep it up to date etc)?

On avr, I chose one of the 3 variants for the mega16, included with the
gcc source, as a starting point.


> Speaking of redundancy, I haven't been able to find any documentation on 
> the register-level ABI that avr-gcc expects, and thus what registers I 
> do and don't need to save when writing my own ASM functions.

>From avr-libc-user-manual/FAQ.html#faq_reg_ I've summarised for myself:

   r0          Volatile
   r1          Assumed to be zero. (clr r1 on return)
   r2-r17      Preserved across function calls
   r18-r27     Volatile
   r28-r29     (Y Register) = Data Stack Pointer
   r30-r31     Volatile

> I see conflicting info in the compiler output, with the interrupt
> handlers saving almost all of the upper 16 even if they aren't all
> used, and others apparently not even saving registers they clobber
> (esp r30:r31).

Hmmm, on other targets, I find gcc is smart enough to save only used
registers in ISRs, unless functions are called. (And who'd do that if at
all avoidable?)

On the avr, I wrote all the ISRs in assembler. Even when moving between
targets, this seems easier than mucking with C to do I/O, interrupt
management, and bit twiddling, etc. Then there's no interference w.r.t.
register saving either. ;-)

IMHO, an ISR must unconditionally preserve all clobbered registers and
the psw, or the system cannot function reliably. It would be very odd
for gcc to do anything else, if it really is aware that it's an ISR.


reply via email to

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