avr-gcc 4.7.0 for the brave

Go To Last Post
205 posts / 0 new

Pages

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

Magister wrote:
When you fill a bugzilla entry for it, PM me the number, I'll add myself on the CC list!
It's PR52692

avrfreaks does not support Opera. Profile inactive.

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

ezharkov wrote:
[...] did not quite like __attribute__((always_inline)). It said "always_inline function might not be inlinable".
Are the functions declared as inline?

avrfreaks does not support Opera. Profile inactive.

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

Hello guys, I'm new to avr programming. I tried building avr-gcc with gcc 4.7.0 and binutils 2.22 and avrlibc 1.8 (latest releases), but I seem to be missing some microcontrollers from the available devices list. Mainly the atxmega128a3u, which I'm currently using.

What are the recommended versions for stable builds, which also include the latest microcontrollers? I don't want to be on the cutting edge, just to be stable (don't really care for size optimizations just yet)

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

SprinterSB wrote:
Magister wrote:
When you fill a bugzilla entry for it, PM me the number, I'll add myself on the CC list!
It's PR52692
Thanks for having added me :idea:

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

SprinterSB wrote:
ezharkov wrote:
[...] did not quite like __attribute__((always_inline)). It said "always_inline function might not be inlinable".
Are the functions declared as inline?
No, they were not. Adding inline helped.

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

wek wrote:

volatile char c;

int main (void) {
  __asm__ volatile ("lds  r16, c" ::: "r16");
}

Even more instructive than __attribute__((used)) with c would be to make the usage explicit:
char c;

int main (void) {
  __asm__ volatile ("lds  r16, %0" :: "i" (&c) : "r16");
}

avrfreaks does not support Opera. Profile inactive.

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

Quote:

Mainly the atxmega128a3u, which I'm currently using.

As Atmel's 4.5.1 toolchain does support that device seek out their patch set and find out what the patch that adds 128a3u actually affects. Then make similar mods. to the files in the toolchain source you are using. IOW backport the patch to 4.7.x

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

clawson wrote:
Quote:
Mainly the atxmega128a3u, which I'm currently using.
As Atmel's 4.5.1 toolchain does support that device seek out their patch set and find out what the patch that adds 128a3u actually affects.
The Atmel 4.5.1 patchset does not introduce changes for that device. What do I miss?

@admin: Could this sub-thread be broken out?

avrfreaks does not support Opera. Profile inactive.

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

Quote:

The Atmel 4.5.1 patchset does not introduce changes for that device. What do I miss?

They are violating GPL again? ;-)

(they have made several issues of 4.5.1 but I don't think they've posed the patch set for the latest one yet).

[I'll split this out later - I have to take the cats for a walk now]

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

SprinterSB wrote:

Even more instructive than __attribute__((used)) with c would be to make the usage explicit

Maybe, but it's not worth the hassle right now. In a new code I'll consider that.

In some of the inline asm pieces the direct use of address in inline asm was necessitated by running to the limit of constraints (yes they are lengthy). IIRC they are all ISRs so they might be replaced by "regular" assembler, but I'd expect that that approach would require to use the "used" attribute for -flto too.

JW

Last Edited: Fri. Apr 13, 2012 - 05:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wek wrote:
SprinterSB wrote:
-mstrict-X -fno-tree-loop-optimize
Without attempting to understand the implications of these switches...
At least they don't hack the ABI as opposed to -funsigned-char, -fshort-enums or -fpack-struct. These switches are 100% pure releted to optimization and don't affect the ABI.
Quote:
...or their relationship to my programming habits, I added both to the experimental setup and they yielded further [...] maybe around 1% [...] reduction of the code size.

I am a firm believer of "go asm if you want absolute control" approach - but it's nice to know that there are still ways how to squeeze out more juice...

I agree with "need of absolute control implies assembler".

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.

wek wrote:
I guess this is one of the things which attracts you to the playing with the compiler, isn't it...
Not easy to answer that.

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.

avrfreaks does not support Opera. Profile inactive.

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

clawson wrote:
Quote:
so the "just drop it at AVR-Libc because there is no better place"?
Not at all. Put it in the one place where everyone using avr-gcc goes to learn how to use it.

I spend my life on this message board pointing people at: ... as the hub of info for using avr-gcc. It would seem a shame to water this down and splatter it across 20 different documents/web sites. If all questions can be answered by: "Visit this link and read everything there" then surely that's a good thing?

Or do the GCC developers somehow look down their noses at the lowly AVR-LibC developers and don't want to "give them the credit" or some other shit like that?

Why do you think I discredit avr-libc or its developers and write such nonsense? That's plain bullshit!

This is what I think:

Quote:
one place where everyone using avr-gcc goes to learn how to use it

Yes, it's a good thing to have a canonical place to learn about things. One place is the tool's/component's documentation.

If there is more elaborate explanation with worked out examples, description of how things interact and all these things, that's certainly a good thing.

Quote:
A "Visit this "link" and read everything there" then surely that's a good thing?

I don't think dropping anything at one place is a good thing. A good tutorial should be selective and pick instructive example and work them out.

"The more the better" does not hold IMO.

Flooding such a site will all kinds with information is not helpful at all to the beginner. For a noob there is so much new stuff that he must be overwhelmed by it: New editor environment, new hardware and all the oddities of a new language like C. And we all know C has many oddities and features that are non-intuitive. Getting the hardware settings right like baud rate, like fuse settings, like JTAG, like interrupts, like finding SFR and bit names, like finding right header. Connecting all that stuff and controlling the programmer. Learn what tools are there and how they interact. Understand what's going on under the surface and besides all the obfuscation introduced by tools. (If, for example, you don't see that an error message is from the linker or even are aware that there is something like a linker, it's much harder to understand the error message and the solution). Understanding build and make process. And many, many more.

There are so many things that are new that a noob will drown in all that information.

And I think the link/information I posted above is simply too unimportant to be dropped at such a place and distract noobs, confuse them, put focus on things that are completely irrelevant at that time.

Quote:
I spend my life on this message board pointing people at: "link"
Spend the life with "Read the fabulous manual", then? Well, if there is request like

"Urgent! I am late with my project but there is an error. Pls. give details description as soon as possible!"

then I don't even waste a single second on it. Spending the whole life for it is the other opposite...

If people don't even care for what they are actually doing, don't care for what tools that they actually use, don't care for what documentation is included. How am I supposed "link" would help them?

avr-gcc documentation links to avr-libc. WinAVR documentation comes with avr-libc documentation. Even in PDF. Even with elaborate examples. Even with detailes description of how tools interact. Even with detailes description what subpackages are included and where they are hosted.

Quote:
wiki

As I wrote, a wiki-based system is much less effort than a patch-based one.

Still can't believe and don't understand why people prefer to write "[TUT] as thread" and produce tapeworm threads with up to several hundreds of posts. And just beneath there is a wiki perfectly suitable for such information, with much better web-typographic, with categories for articles, with graphics, with chapters and sections, with table of contents, with history, with authors that can be talked to, with discussion page. How old is wiki paradigm and technique now?

But completely bypassed, ignored, deserted, for whatever reason.

@admit. Maybe the "tweak options" can be broken out?

avrfreaks does not support Opera. Profile inactive.

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

Quote:

Flooding such a site will all kinds with information is not helpful at all to the beginner.

You don't need to worry about beginners - evidence here suggests they don't read the documentation anyway. But experts know where to look and they would like all the documentation in one place.

Already this page has been growing recently:

http://www.nongnu.org/avr-libc/u...

Just adding a few more pages to articles of use does not mean that the reader is going to feel "swamped" by over-information.

Quote:

then I don't even waste a single second on it.

Well personally I do like to try and help beginners get started because I was one once and know what it's like. The great thing about GCC is that there is such a great manual (even an online copy) so that the majority of questions ("how do I use EEPROM?", "how do I store data in flash?", "why are my ISR/main variables not updated?") can be answered by it.

Oh and the Atmel Wiki failed because it is was hosted on a server powered by steam and rubber bands (anyway that was about "AVR" in general, not avr-gcc in particular).

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

clawson wrote:
Quote:
then I don't even waste a single second on it.

Well personally I do like to try and help beginners get started because I was one once and know what it's like.
Please don't put what I said into the wrong context. The "urgent help asap" it not related to beginners or noobs or experts or in any way to the degree of knowledge or expertise of the asker.

It's solely related to friendlyness and netiquette and against the "you help me a.s.a.p. because me to lazy to RTFM" attitude.

avrfreaks does not support Opera. Profile inactive.

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

Yes but 99% of the time these people are "needy" because it wasn't obvious to them where to look for the manual that would answer all their questions.

It does seem a failure of everything that installs avr-gcc in either a Windows or Linux environment that it does not make it much clearer where the installed copy of the manual (which I take to be the AVR-LibC HTML or PDF files) have been installed on the user's hard drive.

To me trying to use something as complex as a optimizing/linking compiler without at least a brief look at some over-view and a quick summary of the most often used command line options is doomed to failure (I'm always reminded of Gert Frobe flying a plane for the first time in "Those Magnificent Men In Their Flying Machines" - but at least he was reading the manual as he went along - the first landing being the most "interesting" bit - it's only when the seagull steals the manual that he really becomes unstuck).

All installation programs should as a very minimum say "if you don't do anything else at least take 5 minutes to familiarize yourself where "this" is located as you ARE going to need to refer to it at some point".

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

Quote:
Yes but 99% of the time these people are "needy" because it wasn't obvious to them where to look for the manual that would answer all their questions.

You sure, Cliff? So you just reserve a tiny 1% to reasons like
- Oh man, i can do that within 2 days, and there's a month left for the assignment
- My girl friend has just asked to go to the cinema
- I just didn't make it yet to that fancy new disco in town
- Manuals??? What's the teacher for then???
- Thinking of scheduling my project? Naaah, there's that superfreak that throws complete solutions even for the most demanding and lazy guy.

Your confidence in the average student seems to be quite high. I know, we were all novices one day, but some of us had a student life some 20 years ago as well, right?

Einstein was right: "Two things are unlimited: the universe and the human stupidity. But i'm not quite sure about the former..."

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

DO1THL wrote:

- My girl friend has just asked to go to the cinema
- I just didn't make it yet to that fancy new disco in town

Cinema? Disco? LOL!

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

More findings.

1. More "unused" variables were dropped, but went unnoticed initially. This time, it was a block of data allocated to a fixed position in FLASH through a "manually" assigned section, and never used in C program. It is used as an identification for other utilities.

Johann, could you please help me locating the switch for the linker to print the "dropped" variables?

2. This was fatal: I have "reserved" registers such as (note that I am already paranoid to add the "used" attribute everywhere):

register unsigned char __attribute__((used)) _r2 asm("r2");

yet the compiler uses them throughout. As I use these in ISRs, this had various "funny" consequences (the code was mostly working though).

It appears that -ffixed-2 et co. helped on this.

If the "allocation through asm("rX") is officially non-functional now, you should perhaps submit a patch for the relevant section in avr-libc's documentation http://www.nongnu.org/avr-libc/u...

Jan

PS. I've just noticed, that with -ffixed-X in place and with no other changes, the program's size *decreased* further - from 141863 bytes reported previously, to 138827 bytes... Shall I feel disturbed? :-?

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

wek wrote:
Johann, could you please help me locating the switch for the linker to print the "dropped" variables?
Skimming ld options will take 5 minutes: http://sourceware.org/binutils/d...

I am no ld compendium, sorry ;-)

wek wrote:
I have "reserved" registers such as (note that I am already paranoid to add the "used" attribute everywhere):
register unsigned char __attribute__((used)) _r2 asm("r2");

yet the compiler uses them throughout.

Paranoia is a bad replacement for Correctness :twisted:

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

register unsigned char r2 asm ("r2");

ISR (some_vect) {}

and avr-gcc allocates R2 in some_vect?

wek wrote:
I've just noticed, that with -ffixed-X in place and with no other changes, the program's size *decreased* further
Yes, it's a known paradox of the register allocator. There are still bugs open like PR52778 which won't be fixed for 4.7, maybe it's related to it but I don't know. Register allocation is much too complicated I will ever understand it...

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
wek wrote:
Johann, could you please help me locating the switch for the linker to print the "dropped" variables?
Skimming ld options will take 5 minutes: http://sourceware.org/binutils/d...
Believe me that I've spent considerably more time, to no avail. Apparently -flto being a new feature, maybe there's no such option yet - and in GNU world the sources are the best documentation anyway, aren't they... ;-)

SprinterSB wrote:
Be more specific and show an example,
I'll try later. I am not at *that* computer now. And, as could be expected, it took quite a complex routine to press the compiler to go down to r2. But I'll try to generate some example.

SprinterSB wrote:
presumably you betray the compiler.
I don't understand.

SprinterSB wrote:
Are you saying you have
register unsigned char r2 asm ("r2"); 
ISR (some_vect) {}

and avr-gcc allocates R2 in some_vect?

No, I am using r2 in inline asm in naked ISR (without store/restore of course; and without mentioning it in the clobbers, to be absolutely precise). The compiler allocated r2 in other, "plain" functions.

SprinterSB wrote:
wek wrote:
I have "reserved" registers such as (note that I am already paranoid to add the "used" attribute everywhere):
register unsigned char __attribute__((used)) _r2 asm("r2");

yet the compiler uses them throughout.

Paranoia is a bad replacement for Correctness :twisted:
The _r2 variable is not used anywhere, indeed, so after that previous experience it appeared to me that the "used" is appropriate here, too. The "asm("rX")" is a non-standard gcc extension, as well as the "used" attribute - how am I as a user supposed to know what's correct in this context?

Johann wrote:
wek wrote:
I've just noticed, that with -ffixed-X in place and with no other changes, the program's size *decreased* further
Yes, it's a known paradox of the register allocator.
Okay, I see, and am not surprised...

Jan

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

wek wrote:
[reading docs] Believe me that I've spent considerably more time, to no avail. Apparently -flto being a new feature, maybe there's no such option yet.
Ok, you didn't say it's a problem together with LTO. The first place to ask is respective binutils or gcc mailing lists like gcc-help@gcc.gnu.org. Yes, I know it's not that chatty-chatty like here and you must be specific and follow netiquette.

wek wrote:
SprinterSB wrote:
Are you saying you have
register unsigned char r2 asm ("r2"); 
ISR (some_vect) {}

and avr-gcc allocates R2 in some_vect?

No, I am using r2 in inline asm in naked ISR (without store/restore of course; and without mentioning it in the clobbers, to be absolutely precise). The compiler allocated r2 in other, "plain" functions.[...] The _r2 variable is not used anywhere.
It's not about used/unused, it's about making the register global if it's required that the compiler does not allocate it. This may even be required in modules that don't even mention R2. If you make R2 global in a.c but call functions in b.c without making R2 global in b.c, that's a bug.

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.

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
It's not about used/unused, it's about making the register global
I know that.

I spent quite some time trying to reproduce the problem, but I can't reproduce it on my home computer... The sources I have here are somewhat older, but the routine where I have seen the r2..r5 registers be used is unchanged... I don't understand.

Tomorrow at work I will get back to the problem (if time permits) and will report.

JW

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

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

avrfreaks does not support Opera. Profile inactive.

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

I have spent many hours trying to produce a minimal example, to no avail. Only if I compile the whole project the problem appears (registers r2-r5 are used in some functions originating in C, even if they were "forbidden" defining "register unsigned char r2 asm ("r2");" as global variable).

Findings:
- this is clearly a LTO problem in linker (during linking): the "forbidden" registers are NOT present in the assembler output from compiler, only in the linked result in .elf

- in functions where the "forbidden" registers appear in the .elf, they are properly pushed/popped in prologue/epilogue (except for main(), which appears to have stripped prologue/epilogue, but that was expected)

- I made sure that the "forbidding definitions" are present in every C source - some of the files with functions small and simple enough not to use the "low" registers ever did not have them before - no change

- could not reproduce the problem when trying to compile and link one of the smaller functions which in the big project exhibited the problem separately from the project, even if the assembler output from compiler is exactly the same (except it has one more unused label) in both cases - in the "minimal" experiment the linker maintains a small stack frame, whereas in the big project it replaces it with the "forbidden" registers

- it is enough to use -ffixed- during linking to remove the problem

- it is not sufficient to use -ffixed- during compilation (and not use it during linking) - in that case problem persists

I now can't spend more time on this. I am willing to cooperate in experiments if anybody has ideas what to try to do next.

JW

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

I saw this post from a few days ago. Has anybody tried his instructions on building?
http://maniacbug.wordpress.com/2...

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

I'm having a problem compiling for an Xmega32A4U. I'm trying to use what seems to be the latest version you linked. I'm using it from within AVR Studio 5.1, setting it as the toolchain to use for one of my projects. The error is below, that it doesn't recognize the 32A4U. iox32a4u.h is also missing from the include directory, so I guess it just isn't supported by this version of avr-gcc. It seems odd that it isn't. Do you know why?

(Some stuff stripped from here)
C:\Program Files\Atmel\AVR Studio 5.1\make\make.exe all 
kvrx_serial.cpp
		Invoking: AVR8/GNU C++ Compiler
		"C:\ProgramFiles\avr-gcc-4.7-185693-mingw32\bin\avr-g++.exe" -funsigned-char -funsigned-bitfields -DF_XOSC=16000000UL  -I"../../../../Xmega/KVRx" -I"../../../../Xmega/KVRx/libraries/xTSL2561" -I"../kvrx"  -O0 -fpack-struct -fshort-enums -g2 -Wall -c -MD -MP -MF "kvrx/kvrx_serial.d" -MT"kvrx/kvrx_serial.d"  -mmcu=atxmega32a4u   -o"kvrx/kvrx_serial.o" "../../../../Xmega/KVRx/kvrx_serial.cpp" 
avr-g++.exe(0,0): unrecognized argument in option '-mmcu=atxmega32a4u'
		avr-g++.exe: note: valid arguments to '-mmcu=' are: (long list removed, other stuff stripped.)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

avrfreaks does not support Opera. Profile inactive.

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

I wasn't asking why it isn't working, I was asking why that device isn't supported in the expected way. I realize it's fairly new, but my impression was that devices were often supported before they were even released. I'm more wondering about the process that gets MCUs fully supported (you seem to have some insider knowledge) than how to get it working (my current setup is working fine for me).

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

hardmanko wrote:
I was asking why that device isn't supported in the expected way.
Because noone added support for the device in GCC/binutils/AVR-LibC. Noone deemed it important enough, and it's really hard to not get puzzled by the plethora of hundreds of AVR devices, many of them 100% identical.

Quote:
my impression was that devices were often supported before they were even released.
A device is supported if it's support is added. many of the devices are 100% identical from the compiler's view who has only to care for the instruction set. Same is true for binutils.

Quote:
I'm more wondering about the process that gets MCUs fully supported (you seem to have some insider knowledge) than how to get it working.
Vast majority of changes will be to AVR-LibC: Startup-Code and non-libc changes to libc. AVR-LibC ships device support like EEprom routines not in an own device support library. Instead, it adds support functions for each device to libc and uses a device-unique name to refer to it.

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

avrfreaks does not support Opera. Profile inactive.

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

That's interesting, thank you for describing the process. I kind of understood that the compiler didn't need extremely device specific information -- like specific register addresses, etc. -- that are in the header file, but I didn't realize that AVR-LibC did so much at the low level. I just assumed that it provided common C functions like printf and some stuff like delay. I should have known better, because I use interrupt.h quite a bit, but I never thought about how it fits into the rest of the toolchain.

Thanks again!

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

hardmanko wrote:
I kind of understood that the compiler didn't need extremely device specific information
There are just very few exceptions to that rule, for example with
extern char c;

void set (char x)
{
    if (x)
        c = 0;
}

Compile for AT90S8515:

set:
	tst r24
	breq .L1
	sts c,__zero_reg__
.L1:
	ret

Compile for AT90S8535:

set:
	cpse r24,__zero_reg__
	sts c,__zero_reg__
	ret

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.

Quote:
I just assumed that it [AVR-LibC] provided common C functions like printf and some stuff like delay.
No, because it would be much too hard for users to add -lavr to the linker call if device-specific stuff was in a stand-alone libavr.a. Such a layout would cause tsunamis of bug reports and support requests...
Quote:
I use interrupt.h quite a bit
interrupt.h, in turn, just contains syntactic sugar, there is no library support required. Just skim the preprocessed sources with -save-temps -g3, for example, or the assembler output. There will be no library calls, it's all chewed by the compiler already.

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
hardmanko wrote:
I kind of understood that the compiler didn't need extremely device specific information
There are just very few exceptions to that rule, for example with
extern char c;

void set (char x)
{
    if (x)
        c = 0;
}

Compile for AT90S8515:

set:
	tst r24
	breq .L1
	sts c,__zero_reg__
.L1:
	ret

Compile for AT90S8535:

set:
	cpse r24,__zero_reg__
	sts c,__zero_reg__
	ret

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


Minor observation:
This particular erratum is officially acknowledged in Atmel's published AT90S8515 errata sheets:
http://www.atmel.com/Images/DOC1... (rev B silicon)
http://www.atmel.com/Images/DOC2... (rev C silicon)

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

lfmorrison wrote:
This particular erratum is officially acknowledged in Atmel's published AT90S8515 errata sheets:
Yes, I know. But only after asking the Atmel support about affected devices because I observed bug-specific code/comments in binutils.

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...

avrfreaks does not support Opera. Profile inactive.

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

You're right, Atmel's current method of publishing errata is really only useful for end-users of particular devices - it's pretty horrible for people who are trying to maintain tools which apply to many different devices.

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

Johann,

in your build, http://sourceware.org/PR13410 appears to be fixed, even if the bug report says fixed for binutils 2.23 while your build contains 2.22.

Can you please confirm?

Thanks,

Jan

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

wek wrote:
in your build, http://sourceware.org/PR13410 appears to be fixed, even if the bug report says fixed for binutils 2.23 while your build contains 2.22.
My build neither contains 2.23 nor 2.22, it contains 2.22 HEAD as mentioned in the note alongside the download link.

Binutilas are not as eloquent as gcc that says 4.6.1 or 4.6.1 DATE (experimental) or 4.6.1 DATE (prerelease).

In GCC speek it would be 2.23 (experimental) I guess?

As you might know, binutils uses CVS as VCS where versioning is really confusing, at least to me...

avrfreaks does not support Opera. Profile inactive.

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

Okay, I see. Honestly, I did not go back to the post where you gave the link, sorry.

I take it as "yes", then... :-)

Thanks,

Jan

PS. This was one of the two linker bugs I came aware throughout the years here on avrfreaks. The other is related to gs() (thus 'M256x, maybe the bigger XMegas too) and *no* -relax; a quick check reveals that that one still persists.

PS2.Submitted the latter to binutils bug tracker

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

Thanks for the problem number (PR14058)

avrfreaks does not support Opera. Profile inactive.

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

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

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

avrfreaks does not support Opera. Profile inactive.

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

Nice! Cannot wait for an offical release with latest binutils and avr-libc!

GCC guys are impressive!

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

Magister wrote:
Cannot wait for [...] latest binutils
Unfortunetly, there are some open bugs in binutils. It appears that even if there are approved patches, nobody would install them...

avrfreaks does not support Opera. Profile inactive.

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

I uploaded a new snapshot "avr-gcc-4.7.1-rc1-mingw32.zip" to the same directory as the other snapshots.

  • Binutils fixes some wrong code issues with --gc-sections and --relax
  • Binutils supports XCH, LAS, LC, LAS instructions
  • Binutils supports data expression modifiers like .byte lo8 (symbol)
  • avr-gcc comes with a working -mint8.
  • For a more complete list problems fixed in 4.7.1, see Bugs Fixed in 4.7.1
The zip file is bigger (45MB inflating to 110MB) because it includes documentation (info, man, html, pdf).

For notes on how to "(un)install" the toolchain, see the notes with the previous snapshots.

Versions:

  • GCC is 4_7-branch SVN 188257 (4.7.1 release candidate)
  • Binutils is trunk (future 2.23) from today with some pending patches
  • AVR-LibC is 1.8.0 trunk SVN 2294 from today

avrfreaks does not support Opera. Profile inactive.

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

It works fine here, LTO is working too for the first time for me, gained an extra 50 bytes :)

You are the man 8)

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

Thanks SprinterSB, I would like to build that on Linux (Fedora 16 I686). Should I use just the SVN versions or are there more patches that I need to apply?

AFAIK, newer XMEGA devices are still missing (to be more specific, I look for xmega32a4u). Please correct me if I'm wrong.

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

itai_n wrote:
Thanks SprinterSB, I would like to build that on Linux (Fedora 16 I686). Should I use just the SVN versions or are there more patches that I need to apply?
Download the zip and have a look at the patches in ./source

itai_n wrote:
AFAIK, newer XMEGA devices are still missing (to be more specific, I look for xmega32a4u). Please correct me if I'm wrong.
I wrote somelines on how to support "unsupported" devices. It basically boils down to having the device header and startup-code. The blueprint for startup-code can be found in AVR-LibC and maybe also the divice headers which are plain text.

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

Magister wrote:
LTO is working too for the first time for me, gained an extra 50 bytes.
For my application I get -1.6% for code size so it is not too bad. LTO is just used for some modules where I want cross-module inlining.

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...

avrfreaks does not support Opera. Profile inactive.

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

Thanks for the build, Johann.

Findings:
- you did not include the patch I posted at http://sourceware.org/bugzilla/s... , did you find any problem with that?

- with -flto, the problem with the linker using "reserved" registers I reported above persists

- with -mstrict-X, several functions won't compile, an example output:

smd_switching.c: In function 'SwitchLocalBPF':
smd_switching.c:824:14: error: can't find a register in class 'BASE_POINTER_REGS
' while reloading 'asm'
smd_switching.c:828:13: error: can't find a register in class 'BASE_POINTER_REGS
' while reloading 'asm'
smd_switching.c:841:26: error: 'asm' operand has impossible constraints
smd_switching.c:824:14: error: 'asm' operand has impossible constraints
smd_switching.c:828:13: error: 'asm' operand has impossible constraints

All lines reported above contain pgm_read_byte_far(SOME_CONSTANT_OFFSET + some_16_bit_variable). The functions are lengthy (which is IMO expected for the kind of error above), which is why I can't provide a minimal example at the moment, but am willing to discuss/cooperate if you are interested.

- without -flto the application I used above for the tests compiles and appears to run correctly

Jan

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

wek wrote:
you did not include the patch I posted at http://sourceware.org/bugzilla/s... , did you find any problem with that?
I simply missed that. Other patches like this one are not in a valid diff format and patch terminates with an error. You can minimize such problems if you attach the patch to the PR instead of copy-pasting it.

In easy way to get a patch is

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

Quote:
with -flto, the problem with the linker using "reserved" registers I reported above persists
Test case is where?

Quote:
with -mstrict-X, several functions won't compile, an example output:
error: 'asm' operand has impossible constraints

Something is wrong with your inline assembler. It's not a compiler bug.

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
Other patches like this one are not in a valid diff format
But you apparently managed, haven't you? :-)

IMHO that's one of the points of the plaintext and almost-human-readable format of diffs. I guess diff/patch back then started with people posted smaller changes simply by quoting the changed lines, manually adding "-" and "+" to them as appropriate; and diff/patch only "machinized" the process to allow for larger changes and automated processing.

SprinterSB wrote:
and patch terminates with an error.
That's because patch is ignorant of the DOS/UNIX line ending differences. Using -l with path alleviates this problem (although I am not sure whether it won't introduce some other). Or, you can use any de-CRLF-ier to strip the CRs before attempting to patch.

SprinterSB wrote:
You can minimize such problems if you attach the patch to the PR instead of copy-pasting it.
Certainly. I still have the original output of diff and patch does accept it without -l (and, indeed, only the CRs are the difference).

However, I found it illustrative to post the patch as part of the explaining text. I could have done both; but I was not aware of said patch's dumbness (okay we can call it *nix-centrism, if you want :-) ).

SprinterSB wrote:
Quote:
with -flto, the problem with the linker using "reserved" registers I reported above persists
Test case is where?

As I reported in https://www.avrfreaks.net/index.p... , I could not produce a minimal example. Trust me that I tried hard. For obvious reasons I am unable to post the whole project, but am willing to cooperate in experimentation, although IMHO it is not worth spending more time on it, as it is a minority problem and workaround is known - I would just suggest to mention it in documentation (should any happen).

SprinterSB wrote:
Quote:
with -mstrict-X, several functions won't compile, an example output:
error: 'asm' operand has impossible constraints

Something is wrong with your inline assembler. It's not a compiler bug.

You should start having more faith in that I know what am saying, Johann... ;-)

This is not *my* inline assembler - as I said above, all occurences involve lines with pgm_read_byte_far(). You will find it in . One example of preprocessed output of a line throwing this error:

          eep = (__extension__({ uint32_t __addr32 = (uint32_t)((uint32_t)(0x30000UL + pp + __builtin_offsetof (TCfgRot, eeRot))); uint16_t __result; __asm__ ( "out %2, %C1" "\n\t" "movw r30, %1" "\n\t" "elpm %A0, Z+" "\n\t" "elpm %B0, Z" "\n\t" : "=r" (__result) : "r" (__addr32), "I" ((((uint16_t) &((*(volatile uint8_t *)((0X3B) + 0x20)))) - 0x20)) : "r30", "r31" ); __result; }));

And I did not say it is a compiler *bug*, but it certainly is a compiler-produced, uhm, feature :-) It apparently can't resolve the register pressure in extreme cases. Again, I don't think this is worth to spend more time on this, and would simply "solve" this "problem" by mentioning it in documentation.

Jan

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

wek wrote:
SprinterSB wrote:
Other patches like this one are not in a valid diff format
But you apparently managed, haven't you?
It's still inconvenient to manually extract the changes. Better put effort in more reasonable stuff than this...

Quote:
SprinterSB wrote:
and patch terminates with an error.
That's because patch is ignorant of the DOS/UNIX line ending differences.
No. It's because the patch is invalid. Goto the bugzilla page, highlight the text and you see that there are empty lines. That is invalid.

Quote:
but I was not aware of said patch's dumbness
patch is not dump, it is strict. Better reject an invalid patch than making wrong guesses.

Quote:
SprinterSB wrote:
Quote:
with -mstrict-X, several functions won't compile, an example output:
error: 'asm' operand has impossible constraints

Something is wrong with your inline assembler. It's not a compiler bug.
"'asm' operand has impossible constraints" is definitely a user error. The compiler is not supposed to hack around user code, no matter if it comes from you or from some "official" header files.

Quote:

eep = (__extension__({ uint32_t __addr32 = (uint32_t)((uint32_t)(0x30000UL + pp + __builtin_offsetof (TCfgRot, eeRot))); uint16_t __result; __asm__ ( "out %2, %C1" "\n\t" "movw r30, %1" "\n\t" "elpm %A0, Z+" "\n\t" "elpm %B0, Z" "\n\t" : "=r" (__result) : "r" (__addr32), "I" ((((uint16_t) &((*(volatile uint8_t *)((0X3B) + 0x20)))) - 0x20)) : "r30", "r31" ); __result; }));

gives me this error:
eep.c:1:21: error: braced-group within expression allowed only inside a function

avrfreaks does not support Opera. Profile inactive.

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

with 4.7.1 prerelease from 20120322 : 15468 bytes
with 4.7.1 prerelease from 20120606 : 15674 bytes

206 bytes lost :-/ I will use nm to check the functions that got bigger

Pages