AVR-gcc 4.4.2 seems to perform better than 4.3.2

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,
I just compared results of WinAVR gcc 4.3.2 with AVR-gcc-4.4.2 under Linux. Gcc-4.4.2 was provided by distribution packages (Fedora 12), the same project, the same makefile, the same options. I've compiled a relatively big program written in C++, and got the following results:
- AVR-gcc 4.3.2 "“ 43898 bytes,
- AVR-gcc 4.4.2 "“ 42250 bytes.
1648 bytes less, which is only 3,75%, but it is pretty impressive.
The application was pretty complicated (C++ code of GUI interface). I loaded it on target board and checked if everything works ok. It seems that gcc 4.4 produced fully functional code. I think it is a good information for all of us, and especially for these who almost fill the whole available FLASH.
Unfortunately next WinAVR will be still containing gcc 4.3.3, so we have to wait for longer to get benefits under Windows.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I thought Eric said he deliberately wasn't making the 4.3 to 4.4 transition for AVR because there were serious, known AVR issues in 4.4 ?

I think most folks would prefer a 4.3.3 based WinAVR that works rather than a 4.4.x that generates broken code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This post from the avr-gcc list has some background, looks like just a lack of testing rather than specific issues? http://lists.gnu.org/archive/html/avr-gcc-list/2009-10/msg00071.html

I've been fiddling with 4.4.2 since the Fedora update, and haven't run into anything bad yet (although in fairness my test cases have been fairly limited)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You are right Clawson, but in the future Eric just have to switch to gcc 4.4. As I said, my program is relatively big – after compilation 44kB of code, and works perfectly after compilation in gcc 4.4. It doesn’t mean that gcc 4.4 is bugless, but onther people have the same positive experience with gcc 4.4 branch, so it means something. I wonder if we can create a set of test programs which could be used for testing code generated by gcc. We have a good simulators of AVR core, so it should be pretty easy to make a test set and compare results.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TFrancuz wrote:
I’ve compiled a relatively big program written in C++, and got the following results:
- AVR-gcc 4.3.2 – 43898 bytes,
- AVR-gcc 4.4.2 – 42250 bytes.
1648 bytes less, which is only 3,75%, but it is pretty impressive.

Contrary, this appears to me as a marginal improvement.

Especially so, in the light of recent threads of how various compilation switches can (sometimes more pronouncely than by 3.75%) influence code size.

Moreover, you surely are aware of the statistical value of a "benchmark" like this - a single and relatively big C++ program of unknown structure. The vast majority of AVR applications are undoubtedly of a completely different profile. Also, you said nothing on changes in RAM and stack usage (and I doubt you really can establish the latter precisely enough), which is a more precious resource in AVRs than FLASH. And, a lot - if not majority - of AVR users might also prefer speed to code size, which might open another round of discussion on benchmarking.

At the end of the day, I would like to see more development in other directions than raw size and speed reduction (which I see as fairly good at the present anyway), like better documentation, more device libraries, exact stack consumption calculator, native memory classes (a.k.a. named address spaces), better support for "big" memories (FLASH > 64kB/kW), some work in the muddy waters of interrupt-related issues (automatic volatility and atomicity issues resolving) etc. This of course won't happen just by leaning on the mainstream gcc development, which apparently won't give a #$%^ for small embedded systems needs.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TFrancuz wrote:
As I said, my program is relatively big – after compilation 44kB of code, and works perfectly after compilation in gcc 4.4.

I have the opposite experience, I upgraded to Fedora 12 and got gcc 4.4.2 as part of that upgrade. Part of my ~50k code stopped working and there's no obvious logic in what broke and what didn't. Instead of trying to chase down where the problem lies I've simply backed to the 4.3.3 that's distrubuted with Fedora 11 and so far everything seems to be working ok.

I'd avoid 4.4 for now if I were you.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes wek, I’m aware of limitation of my test. But every previous version of gcc produced bigger code, and now it seems that this trend is stopped. Of course for some of us 3-4% space gain can be neglected, but if you are on the edge…
Named spaces will be in gcc 4.5 (I suppose), better support for big memories means that we need memory models. Automatic volatility is not something I want, and it is even hard to imagine how it can work? RAM usage – it depends mainly on user not compiler, so I can’t imagine any big benefits from this side.

Qeruiem – you should try to figure out what is going on – just to help in gcc development. I don’t use 4.4 in everyday work, I rather checked how it performs in compare to 4.3.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is a reason why Embedded programmers stick with older compilers: They know where the bugs are. IMHO, every version of compiler, linker, library, and so on has bugs in it. The real questions are:

1 - Do you know what the bugs are?

2 - Can you live with them (or work around them)?

Sometimes a bug causes so many problems that it is not worth moving to the given compiler/linker/library. Sometimes not.

I happen to agree with Jan, though: 3.75% out of a 44K app doesn't seem to be enough to cause a jump to a reportedly unstable compiler.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stu_san wrote:

I happen to agree with Jan, though: 3.75% out of a 44K app doesn't seem to be enough to cause a jump to a reportedly unstable compiler.

Stu

Yes, but if nobody will test the new compiler it will be unstable forever. And gcc 4.4 is now available in most linux distributions, I think it will be nice to have it under Windows too, even as a beta version.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avr-gcc 4.4 should be better that 4.3
If you check the bugs list you will note there are a lot of fixes made for AVR.

4.5 maybe even better, as new register allocator has had more attention and some fixes have not yet been backported to 4.4.

avr-gcc 4.5 also includes stack usage in assembler files.
I am putting a few improvements into 4.5 at this time. This includes further fixes for bugs reported and hopefully a few correction that will help with code size and speed.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stu_san wrote:
There is a reason why Embedded programmers stick with older compilers: They know where the bugs are. IMHO, every version of compiler, linker, library, and so on has bugs in it.

Couldn't agree more. I won't touch gcc 4.4 until the next stable release is out, THEN I might start to see if I can see what's making the code refuse to work with 4.4. Until then I'll stick with 4.3!

I should probably buy a JTAG too... :roll:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have been known to test the beta version of the compiler and library. If Eric will create a version of 4.4.x for Windoze (unfortunately, my development system right now), I would be happy to try it out.

And just as certainly, I won't put it into production until I've run the resulting code through every regression test I have. :twisted: After all, to quote the immortal John Cleese, "I may be an idiot, but I'm not stupid."

Qeruiem wrote:
I should probably buy a JTAG too... :roll:
Depends on the processor you want to debug. I've heard that DebugWire on the small processors is nice. Of course, on a larger processor, I consider JTAG to be just about essential.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All,

It's not that GCC 4.4 has known, serious issues for the AVR. The issue is that GCC 4.4 introduces a new Integrated Register Allocator (IRA). It is currently unknown how this will generate code for the AVR. Perhaps everything is fine and there's nothing to worry about. Perhaps there are now new bugs never seen before. We just don't know. It hasn't gotten a lot of testing. Andy H. (above) has been doing a lot of work on GCC HEAD (future 4.5) and also on 4.4 and I trust his viewpoints on these issues.

Yes, I would like to eventually release a bleeding edge test version that contains 4.4 so all of those people who would like to try it can do so. Unfortunately right now there are bigger fish to fry, like getting out a new WinAVR release that is incredibly overdue. There are many, many, many new devices in this next release.