AVR Freaks

As I wrote, this is a vanilla toolchain and thus avr-size is unpatched.

I also see crashing avr-ld 2.22 with --relax. So I guess binutils 2.22 are broken; I used them just as any other prerequisite for GCC.

Using binutils 2.21 fixes the problem so best will be I rebuild the tools using binutils 2.21 and update the zip from above.

There is a updated version now that uses binutils 2.21 instead of binutils 2.22. ZIP file name is the same.

For programs that use indirect struct access you can try -mstrict-X option. Similar for C++.

For programs that pass many parametrs on stack (printf et al.) you can try the -maccumulare-args.

I also saw that -foptimize-sibling-calls increases code size in cases when the epilogue is expensive.

If I understand Sebastian correctly, AStudio relies on undocumented stuff that only happened to work in specific GCC versions because of a GCC bug.

Bugs that unintentionally implement a feature are much more likely to pass unnoticed than the kind of bugs mentioned above: bugs that actually break a feature.

As you might already know, yesterday at GCC's 25th anniversary was GCC 4.7.0 released.

Thus, I decided to do a build of the tools from the now actual version of GCC which is 4.7.1 (prerelease). For PRs fixed in 4.7.1, see

Bugs Fixed in 4.7.1

For avr-gcc, the only changes with respect to 4.7.0 are problems related to new features: The Xmega support and the 24-bit address-space __memx.

• avr-gcc is from 2012-03-22 4.7-branch SVN r185693,
• Binutils is 2.23 from 2012-03-22 trunk
• AVR-Libc is 1.8.0 from 2012-03-22 trunk r2291

After unpacking, you can move, rename or delete the directory according to your needs. To use the compiler, just call it by its absolute path or add the ./bin subdirectory to your PATH.

The zip is ~30MB and inflates to ~100MB on disc.

Notice the following limitations with Link Time Optimization (LTO):

• If you intend to use LTO, i.e. compile/link with -flto, use *nix-friendly path names without spaces or other special character.
• LTO does not (yet) work with AVR-specific builtins like used by util/delay.h from AVR-Libc. Having __DELAY_BACKWARD_COMPATIBLE__ defined when util/delay.h is included should avoid this shortcoming (for util/delay.h at least).

Maybe that page should be moved to a more common place...

There is wiki.avrfreaks.net but that site is slloooooow so not real fun, neither for authors not for readers. People obviously prefer to drop their wikiesque texts/tutorials as thread in the forum.

@Magister: Does it work if you use sane path names?

For the text in question I'd very much prefer a less static, wikiesque site. I am thinking of the German mikrocontroller.net or roboternetz.de/rn-wissen.de wiki. In particular the rn-wissen.de has a much more appealing web-typography and -layout than the mikrocontroller.net

Without the extern decl there is a proper error message.

What I don't agree with is "to get significantly better code absolute control is inevitable". "Getting significantly better code" is a completely different thing than "need 100% control over result". Don't confuse them with each other.

Just imagine your example from above: How many additional assembler pieces, sprincled all over the code, would you need to reduce code size by 1%? And how big would the effort be?

Setting/unsetting a compiler switch is a trivial action. What would the "stick to asm if you like to..." approach mean with respect to resources needed and maintainability of the project? It's much less paint so see if, for example, -fno-move-loop-invariants can do the same boost. And it's 100% non-intrusive to the sources.

Don't get me wrong: I also use assembler in my brojects where I want best performance and where it's clear that compiler will never be as smart as brain. But that's no "how better code? --> use asm" reflex.

Some years ago, a friend pointed me to Baumann's Lichtzeitpegel clock sculpture in the Rheinturm in Düsseldorf. I decided to handicraft such a clock, but had absolutely no idea how. My Pa just mumbled "SPS" and with "SPS" I started searching until I came across a model railroader's site that used a "Microcontroller" thing. Even managed to find that site again.

The "µC thing" appeared more reasonable than the "SPS thing" and I bought some of these AT89C2051, a breadboard, a propretieary assembler and programmer and started with the clock. During the project I learned assembler programming, how to decode DCF77 time signals, drive > 40 LEDs per SPI + 74*595, program interrupts and debounce switches, implement a menu, output morse signals to find my way through the menu during setup, drive external 24C02 EEPROM and shake the "alarm", a handicraft wind chime made of aluminium tubes.

And during information minig I came across pages with Nixie tube clocks, and I decided a Nixie clock was the next project.

But the assembler was just an annoyance and the built-in editor was scrap and could not be replaced. And the license stuff was just an annoyance, too. And programming in assembler was no real fun after all, partly because it was assembler, and partly because the assembler's language features were really poor and restricted.

I found almost pin-compatible AVR AT90S2313. And I found avr-gcc readily available with WinAVR, installed it, wrote some C programs, learned how the tools work and interact and what programmer there were -- all before I even bought a single piece of AVR related hardware. The software part looked really good and was kind of deliverance compared to the former assembler IDE.

The next step was the hardware: I started with the 1€ setup: A RS232 breakout, a transistor, some Z-diodes, resistors and a AT90S2313 on a breadboard and connected all that sauerkraut circuit with my computer.

From that point on development was easier and I wasted much less wime with the tools. On the other side, I learned obout the tools and how to apply them in the best way. Knowing about what's under the surface will always enable you to get superior results and work faster and with much more ease.

The WinAVR I used was 20060421 which is avr-gcc 3.4. That compiler produced really good results, but still showed many optimization shortcomings. Thus, I tried newer versions of avr-gcc but observed from version to version that the code size went up according to the genenral rule of thumb: avr-gcc 4.x produced code size increase and thus also speed degradation of 5%-10% compared to good old 3.4.

What then drew my attention to the compiler internals was a thread that reported problems with a wrong code. I knew that source code very well as I wrote it and it float around in the net; but the error was not in my piece of code. Instead, my sorce snippet revealed a "wrong code" compiler bug. I got curious and started digging in the compiler and found the root cause of the defect.

It took me some time to figure out how all the patch and open source projects and process are organized, but finally my first patch was accepted and integrated to fix the aforementioned PR42240. That was roughly one year ago.

To keep on contributing has several reasons:

First, It's a pity to see how such a great project got worse and worse over time, accumulated more and more bugs and flaws that are not fixed.

Second, maybe it's giving something back to a great project, instead of a "expect all for nothing" attitude or a "constantly complain and nag but let others do the job" attitude.

Third, is "hack the project? or hack the compiler?". Hacking around inferior code in the source is never a good thing: It obfuscates the source. It is unstable under migration (new toolchain). It's unstable under porting (other hardware). It's costly to find the places and work out how the hack will be. It has the potential to introduce bugs. It avoids optimization if an updated toolversion actually has the flaw fixed -- you won't even notice it with the hack. And it's simply the wrong place: Fix the root cause, not the symptom! I saw code snippets that praise their use of inline assembler, where the same optimization can be achieved with straight forward C and a compiler change that is smaller than the inline assembler hack!

Fourth, disbelief of the kind "it cannot be that hard to teach the bloody compiler what's trivial and obvious to any assembler programmer". On the surface you just see trivial and obvious goal, like "this instruction is suportluous" or "this sequence could be smarter like so".

Sixth, interest in how a real-world compiler and one of the most important free software works. Solving Sudoku is boring after you solved the 3rd puzzle: They are all the same. With problems in GCC this is different.

Seventh, curiosity. For example "how many of brain's smartness can be packed into a software?". An example is the __builtin_avr_insert_bits buit-in which is rather an exercise in finding a smart solution to a problem than an important or even requested extention.

Eighth, aesthetical reasons. That are changes like code cleanup, coding rules and layout, documentation and readability of source, avoid redundancies, find smart and neat solutions instead of clumsy ones, etc.

I am no ld compendium, sorry ;-)

Be more specific and show an example, presumably you betray the compiler. Are you saying you have

and avr-gcc allocates R2 in some_vect?

If the register (one of R2..R7) is global and reserved there, it must not be used. If it's not global, the compiler may use it, of course.

Registers from R8 on might be required by the ABI. You can reserve them, but there might be clashes with the ABI. There is a warning like PR45099, fixed in 4.7.0.

Don't forget to remove the -ffixed- ;-)

You must give a valid argument to -mmcu=
Otherwise you will get an error.
For a list of valid arguments read the note or the compiler output with --help=target

You can compile code for the architecture by setting -mmcu=avrxmega2 for example. But you will need startup code and header support, too.

Moreover, headers for SFR descriptions, device-specific prototypes like EEprom support routines and vector table definitions are needed.

Compiler and binutils support could be avoided alltogether. The device support is only about header, startup code and libc as mentioned above. The compiler driver just calls the linker with appropriate startup code.o and sets -Tdata and built-in define for the device.

Instead of compiling/assembling with -mmcu=device you just as well can use -mmcu=core -D__AVR_Device__ and add -nostartfiles -Tdata=... -m core to the linker call.

The formal process to add support for whatever feature to GCC or binutils is to provide a patch, and let it approve my respective maintainer. Moreover, you must put your GCC and binutils changes under GPL.

http://gcc.gnu.org/contribute.html

Compile for AT90S8515:

Compile for AT90S8535:

even though both devices are in architecture avr2. This because of some unnamed silicon erratum.

For devices supported by avr-gcc, see ./gcc/config/avr/avr-mcus.def.
For respective binutils list, see ./gas/config/tc-avr.c.

Now you can go and search what the second device is that's affected by this silicon bug...

Is there an official errata list, i.e. a map bug -> device instead of the device -> bug map?

Otherwise, you'd have to read several hundreds of data sheets to find out what devices are affected; not really applicable if you need to find out all affected devices or all core errata that need to be worked around by the tools...

FYI, GCC 4.7.1 release is scheduled for end of next week:

http://gcc.gnu.org/ml/gcc/2012-0...

If you want to add support for a device to the tools, it's a one-lineer:

• ./gcc/config/avr/avr-mcus.def
• ./gas/config/tc-avr.c

Unfortunately, there is PR53595. I hacked around that one by combining the compiler from the march snapshot with binutils from the recent snapshot. Without that hack code size increases by 2% for PR53595 alone.

It's kind of mice-milking business...

In easy way to get a patch is

1. git init
2. git add file
3. change file
4. git diff file > file.diff