Information on AVR GNU assembler

[Mike Thompson]

Hi everyone,

I'm working on optimizing some of the C code for my Atmel AVR based robots into assembly.  Because my applications will be a mix of C and assembly code I would like to use the GNU assembler (GAS) rather than the Atmel provided assembler as GCC and GAS play together nicer.  Unfortunately, I'm having issues digging up information on the AVR flavored version of GAS.  It seems the Atmel flavor of assembly is much better documented across various web sites and examples.  I'm doing alright stumbling along converting the information I'm finding from Atmel assembly to GAS, but I'm running into problems related to how GAS accomplishes certain things such as initialized data segments and such.

Has anyone else done Atmel AVR assembly language programming with GAS? And if so, do you have links to information on using GAS to create code for AVR microprocessors?

Thanks,

Mike Thompson

[Dave Curtis]

Oh, gee, I've done this. Even wrote a custom linker script at some point. It's been a while, though, so I don't remember much of it.

Initialized ram sections are dealt with by putting those variables into a section with a well-known name, ".data" IIRC. The linker script allocates space for that section in ram, and *also* space for that section in program flash. The C runtime contains code to block-copy that flash section into ram before entering main. If you want an initialized variable, you simply need to put it under a .section .data directive.

I presume you found this?
http://www.nongnu.org/avr-libc/user-manual/assembler.html
I think there are also some tutorials at avrfreaks.net.

The avrlibc doc linked above has basic information on how the avrgcc runtime and default linker scripts expect to have things laid out.

The avr-libc-dev mailing list:
AVR-li...@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
is probably a good place to ask questions about avr gas and avr gnu linker scripts. Yeah, it's a little off-topic for the list, but pretty much everybody who knows the straight scoop hangs out there and they are tolerant of intelligent questions regarding low-level avr gcc/gas/linker issues.

You may know this already, but just a reminder: gcc inline assembly is subject to optimizations such as code motion -- in particular, since CLI/SEI don't depend on the contents of registers, the optimizer likes to slide them around :-/

-dave

> --
> You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
> To post to this group, send email to hbrob...@googlegroups.com.
> To unsubscribe from this group, send email to hbrobotics+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/hbrobotics?hl=en.

[Mike Thompson]

Hi Dave,

Thanks for the leads.  I did indeed find most of that on the web. After a few more hours of trying to find documentation to answer my question, but giving up, I went back to trying to figure out how the C compiler initialized the .data section.  Whatever, I put in the .data section of my assembly file was simply being ignored and I couldn't figure out why.  Finally, I noticed at the very end of the C generated assembly file after all the debug information (which I of course was ignoring) there were two magic lines that make everything work:

.global __do_copy_data
.global __do_clear_bss

Adding these to my assembly file magically made my .data sections come alive.  Gotta love these obscure things.

Thanks again,

Mike

[giuliano carlini]

Have you considered inline assembly in your C files? You typically
need to optimize only a few percent of your lines of code, and doing
it inline can be easier.

giuliano

On Aug 17, 2011, at 6:11 PM, Mike Thompson wrote:

[Mike Thompson]

In the past, I've primarily used in-line assembly as needed such as in the OpenServo project.  In this case, I wanted to optimize a whole interrupt handler that was performing quadrature decoding for two motors.  The C code was actually pretty good, but I wanted to see if I could do better.  I was able to get the interrupt handler down to about 2/3 the instructions that the compiler produced with the -Os option.  Since the C code would have been sufficient, much of this was just a learning experience as I tend to shy away from AVR assembly unless absolutely necessary.  Success with this will help put another quiver in my arsenal of tools as I'll be less reluctant to mess with assembly in the future.

Mike