Re: [avr-llvm-devel] Status update

[Weddington, E. <Eri...@at...>]

Hi Borja,

I totally agree that the ABI for AVR GCC basically sucks. However, we have compatibility issues if we hope to win over users. Basically this means that we should endeavor to be able to use avr-libc with avr-llvm, and this means that we have to keep to the same ABI as avr-gcc. Avr-libc is written in mostly optimized assembly, so changing the ABI means an awful lot of work in avr-libc.

However, we should also keep in mind 2 things:

- There has been some talk, here and there, of *eventually* changing the ABI of AVR GCC to something more rational and efficient. The argument stops because of how much work there is to do it and generally not enough resources. But everyone usually agrees that it needs to be done. So I can easily see that the ABI will eventually change in the future.

- To that end, if there is a way for you to do *both* ABIs, and be able to switch back and forth with a switch, then I would highly recommend that you do that. I know it means extra work. But this would be a great selling point. Have it default to the AVR GCC ABI, but if you can come up with a more efficient ABI (and I can do some internal research as to what would be ideal and report back on that) *and* implement it, then it could be shown to users how much better this ABI is *and* that avr-llvm already implements it. Then it would be easier to get the needed work done on avr-libc to switch it over.

HTH,
Eric Weddington

> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...]
> Sent: Wednesday, May 18, 2011 3:00 PM
> To: Weddington, Eric
> Cc: avr...@li...
> Subject: Re: [avr-llvm-devel] Status update
> 
> Hello, while working on the stack and frame stuff a question came to my
> mind. Are we going to use exactly the same ABI as gcc? Basically i'm
> asking this because each time we need to inc/dec the SP we have to use
> many instructions, for example in a function prologue gcc uses 8. From
> what i've seen IAR stores SP in Y so manipulating it doesn't need in/out
> insts, reading SREG or disabling interrupts which is much shorter. When
> passing parameters through the stack to functions it gets longer because
> SP has to be decremented and restored using in/outs on each call. Gah
> Eric, why is SP was mapped in the IO space? xD
> 
> Anyway, if somebody has a better idea let me know otherwise I'll implement
> what gcc does.
> 
> PS: John, with clang do you get doubles or long long variables aligned to
> an 8 byte boundary? I've set their alignments to 1 byte in a constructor
> (cant remember now the name, but it's in the clang patch files in svn) but
> they get aligned too much wasting memory. Any ideas there?
>