[avr-gcc-list] building avr-gcc from svn head?
Does anyone on the list use the latest gcc as a basis for avr-gcc? If so, I'd appreciate any pointers on how to do it. Following the standard procedure I get the error below. Note that I don't need a 100% correct compiler, my student and I are simply interested in having a large set of compilers to play with since we're doing some comparative testing that is aimed at finding compiler bugs. If there are IRA issues we can perhaps help find them. Thanks, John Regehr libbackend.a(avr.o): In function `avr_cpu_cpp_builtins': /home/regehr/avrgcc450/gcc/obj/gcc/../../gcc/config/avr/avr.c:231: undefined reference to `builtin_define_std' collect2: ld returned 1 exit status ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] avr superoptimizer
On Sat, 18 Apr 2009, Sean D'Epagnier wrote: http://www.avrfreaks.net/index.php?name=PNphpBB2file=viewtopict=77805 This is cool, though I largely agree with the message in this thread which says that most of the time, poor avr-gcc output should simply be filed as bugs in the AVR backend. The superoptimizer must be extremely careful in rewriting loads and stores. Probably the best policy would be to never duplicate or eliminate a memory operation. The reason is that volatile qualifiers have been lost by the time the compiler finishes. Sean the limit case of what you are working on is something like Diablo, you should read some of their papers: http://diablo.elis.ugent.be/publications It is an excellent tool. Many benefits of something like Diablo come from optimizing the application and all of its libraries together. Someone should figure out how to get this kind of benefit for AVR. I have spent a bunch of time looking at avr-gcc output over the past couple weeks and have seen many cases where better code could have been generated by perforing IPO on the application + libraries. In many cases simply propagating constants into avr-libc would get most of the benefit. John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] avr superoptimizer
Sean is your code available? A quick scan of the AVR Freaks thread didn't show it. Thanks, John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] avr superoptimizer
That's why I'm (desperately) hoping that the LTO project in GCC will eventually help in this area. http://gcc.gnu.org/wiki/LinkTimeOptimization Alternatively, an LLVM backend for AVR would give this capability (approximately) for free. John ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] avr superoptimizer
On Mon, 20 Apr 2009, Weddington, Eric wrote: Unfortunately diablo looks a bit stale. Their latest release was over 3 years ago (Feb. 2006), and their required patches are for binutils 2.13 and gcc 3.3.2. :-P Is this project even a going concern anymore? I don't think so. And anyway I think doing LTO in the compiler is a better idea-- more information is available. But the Diablo papers are useful and informative and give some ideas about what degree of improvement is obtainable using this sort of approach. John ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] when is it safe to use -mtiny-stack
It's not safe at all. The 3290P has 2K of RAM which gets used for static variables, stack space and heap (if you use dynamic memory allocation). -mtiny-stack will cause the compiler to only change the lowest 8-bits of the stack, which means that you effectively only have a 255 byte stack. Can you guarantee that your application does not use any more stack space than this? Do you have complete code coverage in your testing to prove this? Can I have source code for the program we are talking about? I'm working on a stack analyzer. Currently it does not support the tiny-stack case but certainly that would be nice. John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] when is it safe to use -mtiny-stack
On Tue, 7 Apr 2009, Anatoly Sokolov wrote: The -mtiny-stack may (and should) be used only for devices with 0xFF max RAM adderss, i.e. if SP register is 8-bit. All devices with 1KB and 2KB FLASH memory satisfy this condition, now. Is it not sufficient for the maximum extent of the stack to be 256 bytes? John ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Any SimulAVR or avrtest users out there?
For the sake of discussion here, what makes it very easy to extend? Avrora makes it easy to write monitors which are Java classes that can receive callbacks when many interesting kinds of simulator events occur: memory operations, instruction execution, interrupts, etc. A majority of the little simulator hacks that we end up needing turn out to be conveniently expressible as monitors. You can drop in a monitor without even recompiling the simulator. There are other things I'm leaving out, but the monitor interface is the main thing I used. A few random monitors I wrote or hacked on were: - a simple printf, triggered by a store to a magic memory location - terminate simulator on a break instruction - keep track of maximum stack depth - take timing measurements between specified starting and stopping addresses - profiling the kinds of values stored in regions of RAM There are a bunch more. Obviously you can hack this kind of functionality into any simulator, but here it is easy and convenient and you don't clutter up the simulator core. John ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Any SimulAVR or avrtest users out there?
Avrora's main advantage is that it simulates radio chips (CC1000, CC2420, etc.) found on sensor network nodes. These would be a lot of trouble to replicate, so I doubt that Avrora's going to go away no matter how good the new simulavr gets. Avrora is also very easy to extend compared to every other simulator I've hacked. John Regehr On Wed, 11 Mar 2009, Sascha Silbe wrote: On Wed, Mar 11, 2009 at 10:13:52AM -0600, Weddington, Eric wrote: There's a lot of new work being done at the SimulAVR project: http://savannah.nongnu.org/projects/simulavr FYI: There's avrora [1] as well. While it's written in Java (which I detest), it worked so much better for me than simulavr* that I switched (and even wrote patches). Don't know how much simulavrxx evolved since, though. [1] http://compilers.cs.ucla.edu/avrora/ CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: More volatile musings [was: Re: [avr-gcc-list] memcpy() : problem when passing destination pointer]
Hi Eric- I'm willing to do some avr-gcc bug-finding but (most likely due to my own ineptitude and lack of spare time) I always run into problems building the latest and greatest. I just checked avr freaks and found a pointer to build scripts for avr-gcc-4.3.3. Would bug reports for that version be useful? If not is there a definitive script for building a fully patched avr-gcc-pre-4.4.0 on Linux? Thanks, John Regehr On Thu, 12 Feb 2009, Weddington, Eric wrote: -Original Message- From: avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu. org] On Behalf Of Andy Warner Sent: Thursday, February 12, 2009 7:23 AM To: avr-gcc-list@nongnu.org Subject: More volatile musings [was: Re: [avr-gcc-list] memcpy() : problem when passing destination pointer] Here is a paper on the volatile performance/conformance of various compilers (mostly gcc-based.) Including avr-gcc: http://www.cs.utah.edu/~regehr/papers/emsoft08-preprint.pdf While most of the problems referred to in this thread (and all the problems in Vincent's original posting) were programmer-induced, the paper does talk about how the compilers can error, how to detect it and possible workarounds. FYI, Dr. John Regehr, and Eric Eide were kind enough to let me review a pre-print of that paper some months ago. I agree that it is a very interesting paper, and I'm very interested in incorporating their testing system too. Yes, there is certainly enough work to do. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Most reliable version of avr-gcc?
You might find Table 1 of our recent paper interesting. The paper's here: http://www.cs.utah.edu/~regehr/papers/emsoft08-preprint.pdf There are three lines that show empirical failure rates for avr-gcc 3.4.3, 4.1.2, and 4.2.2, in terms of volatile errors and regular old miscompilations. It is interesting that the functional error rate for avr-gcc is significantly higher than x86-gcc. My guess is that the miscompilations that we are seeing are the known problems in the avr backend that are sometimes discussed on this list (last discussed in the context of the new integrated register allocator, I think). John Regehr On Wed, 17 Dec 2008, David Carr wrote: By reliability, I mean least probability of undetected errors in machine code generation. IE: The machine code conforms to the source code. Thanks, -DC Weddington, Eric wrote: -Original Message- From: avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu. org] On Behalf Of David Carr Sent: Wednesday, December 17, 2008 2:34 PM To: avr-gcc-list@nongnu.org Subject: [avr-gcc-list] Most reliable version of avr-gcc? If one were to compile a program for the AVR where reliability was far more important than code size or performance optimizations, what version of avr-gcc would you choose? What do you mean by 'reliability'? ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: AVR LLVM backend?
Of course they'll want to support PIC on PIC. I know a guy who has a project called SHARC, I suggested that he port it to the SHARC processor... John On Mon, 17 Nov 2008, Dave N6NZ wrote: Weddington, Eric wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of John Regehr Sent: Thursday, November 13, 2008 9:23 PM To: David Brown Cc: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] Re: AVR LLVM backend? I'm pretty sure this is not an issue (anymore, at least). I could be wrong. The recently-added PIC port of LLVM would be a good place to start looking. Ummm... are you sure they mean PIC as in a processor from Microchip, or do they mean PIC as in Position Independent Code? That particular collision in the acronym name space is a frequent cause of confusion among embedded developers -dave Oh, really?! I didn't know that they supported PIC. How interesting PIC is of course a particularly evil target. I claim that if it can be supported at all, AVR should be easy :). ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: AVR LLVM backend?
of compiler geeks hanging around looking for an interesting challenge. Maybe we can bait (did I say that?) one of those folks into adopting the AVR, simply because it is an intellectually interesting puzzle. The LLVM people have a wish list here: http://llvm.org/OpenProjects.html would be nice to get the AVR backend added to this. Perhaps a bit of support could be gotten from Google's summer of code? http://code.google.com/soc/2008/ They have had LLVM projects before it looks like. Or maybe Eric could make a bit of Atmel support materialize? It could be pretty cheap :). If the backend does materialize, I volunteer to beat the crap out of it with my random tester! John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] AVR LLVM backend?
In my opinion the advantage of llvm-avr-gcc wouldn't so much be better code (though it may be a bit better) but rather decreased compiler maintenance effort. The LLVM interfaces seem (1) pretty stable and (2) relatively narrow compared to gcc's. Someone should just do it. A hacky backend supporting only the megas is probably less than a month effort for a reasonable hacker. Then if initial results are promising, others will jump in to help and eventually perhaps an avr-gcc replacement would emerge. In my opinion LLVM needs a few tweaks before it's a really strong embedded compiler. For example its inliner can cause significant bloat even at -Os. But overall it is quite good. On the other hand there are the advantages above plus the developers are extremely responsive. For example in the past year I've been reporting lots of bugs in compilers' implementations of volatile. The LLVM people almost always fix bugs in a few days whereas there's at least one volatile bug that has sat in the gcc bugzilla for 6 months without even being confirmed. As a result LLVM is at present almost totally volatile-correct, gcc has a ways to go. John Regehr -- John Regehr, [EMAIL PROTECTED] Assistant Professor, School of Computing, University of Utah http://www.cs.utah.edu/~regehr/ On Tue, 11 Nov 2008, Weddington, Eric wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Arnim Littek Sent: Tuesday, November 11, 2008 8:32 PM To: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] AVR LLVM backend? On Wed, 12 Nov 2008 16:14:10 Weddington, Eric wrote: Sorry if this is off-topic, but I was wondering whether anyone has considered adding an AVR backend to the LLVM compiler. Yes. snip considered adding an AVR back end to LLVM? If the latter, can this be talked about? Yes, I have been aware of LLVM and I have considered looking into what it would take to create an AVR backend for that tool. The problem is that there are so few people right now who volunteer to help on the AVR GCC toolchain, that it's not worth the time and effort to splinter off to see if LLVM can produce smaller code for the AVR than GCC. We need so much help right now on the AVR GCC toolchain, I can't afford the time and energy to even look into LLVM. Please consider the environment before printing this email Warning: This electronic message together with any attachments is confidential. If you receive it in error: (i) you must not read, use, disclose, copy or retain it; (ii) please contact the sender immediately by reply email and then delete the emails. The views expressed in this email may not be those of Sirtrack. http://www.sirtrack.com Could you please remove your confidential notice before sending it to a very public avr-gcc-list mailing list which is also archived? ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Re: AVR LLVM backend?
My experience with -fwhole-program -fcombine has been less than stellar. I have seen a 25% code reduction, which is great! But I have also seen up to 25% code *increase*, which is really bad. I would have thought that, at the very least, they would ensure that the code size would not increase. But because of this wide range of results, I can't always rely on those switches, which is a real shame. I think that ad hoc and embedded-inappropriate inlining heuristics are entirely to blame here. Both llvm and gcc use speed-focused inlining where code bloat is an afterthought. For a target like AVR it won't be hard to improve this. John ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: AVR LLVM backend?
front-end language and the back-end target. It also seems that it is easier to add or change parts, which would make development and testing faster, simpler, and less likely to break things. I believe that superior IR design is the main advantage of LLVM. My experience (based on submitting many bug reports to both LLVM and GCC) has been that LLVM is just fundamentally easier to fix due to reduced coupling between its parts. Every bug has been clearly in either the middle-end or a back-end, and fixes tend to be local. From following bug-fixing discussions for gcc, my impression is that fixes are more likely to involve difficult global and/or cross-platform reasoning. See this one for example: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35729 One possible problem with LLVM, as far as I have read, is that it is aimed at 32-bit processors - the LLVM language seems to have little support for working directly with 16-bit or 8-bit data. This may mean that an 8-bit back-end will generate very inefficient code, or will have to work specially hard to figure out what calculations can be done in 8-bit data (somewhat like fighting C's insistence on promoting everything to int, only worse). I'm pretty sure this is not an issue (anymore, at least). I could be wrong. The recently-added PIC port of LLVM would be a good place to start looking. PIC is of course a particularly evil target. I claim that if it can be supported at all, AVR should be easy :). John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Stack usage under heavy inlining
Couple responses: I have a student who has hacked gcc so that stack slots are reused, when possible, eliminating the stack bloat under inlining problem. He has also increased the precision of the live range analysis. All of this is towards the goal of greatly reducing stack memory usage (we can already substantially reduce stack usage vs. default avr-gcc, at least for some applications). He's integrating with IRA now, not sure when this'll all be ready to share. We hope to publish something in the Fall but there's a big gap between publishability and usability. My original stack analysis tool for AVR was too complicated and had to be abandoned. I have a newer, simpler one that needs a bit more work before it can be deployed. It is (in most cases) not hard to compute a stack bound for a single C function. It is also (in most cases) not hard to compute a callgraph for an embedded application. The hard part, which cannot be automated, is turning these parts into a sound and precise global stack bound. To see why this is hard, consider that there may be threads, there may be coroutines, there may be reentrant and/or nested interrupts, etc. John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] A few basic doubts regarding installing AVR-GCC on Fedora 9
I'm happy to help stress-test the new register allocator etc. if someone can make available a script for building pre-4.4 on Linux. For various reasons (my fault I'm sure) from-scratch patching and building has been failing for me on various Ubuntus. John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] wrong code from avr-gcc 4.1.2?
In the code below, avr-gcc 4.1.2 wants to return 1 from func_1() when
compiling at -Os. Specifically I'm compiling like this:
avr-gcc -fwrapv -Os -mmcu=atmega128 foo.c
I believe the correct answer is 0 (this is what avr-gcc-4.2.2 returns at
all optimization levels). I don't think the -fwrapv is relevant here
but include it to be on the safe side.
John Regehr
static inline unsigned long int
div_rhs(const long int rhs)
{
if (rhs == 0) return 1;
return rhs;
}
unsigned long g_66;
long g_73;
int func_1 (void)
{
unsigned long l_86 = -1L;
unsigned long l_93 = -9L;
if ((l_86 = g_73) (1 / div_rhs (l_93)))
return 1;
else
return 0;
}
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] wrong code from avr-gcc 4.1.2?
Hi Eric-
I'm using Kevin Klues' avr-gcc debs for TinyOS. I expect that he built a
patched version but I'll check with him to make sure.
I understand that it may be difficult to find resources to fix a version
other than the latest one. Another possible outcome is that this sort of
thing will motivate TinyOS to switch to a new compiler version. Of course
there are issues with that too...
Compiler output follows. It is not very informative since that function
is nearly optimized away.
John
[EMAIL PROTECTED]:~$ avr-gcc -Os -fwrapv -S small.c -o -
.file small.c
.arch avr2
__SREG__ = 0x3f
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__tmp_reg__ = 0
__zero_reg__ = 1
.global __do_copy_data
.global __do_clear_bss
.text
.global func_1
.type func_1, @function
func_1:
/* prologue: frame size=0 */
/* prologue end (size=0) */
ldi r24,lo8(1)
ldi r25,hi8(1)
/* epilogue: frame size=0 */
ret
/* epilogue end (size=1) */
/* function func_1 size 3 (2) */
.size func_1, .-func_1
.comm g_66,4,1
.comm g_73,4,1
/* File small.c: code3 = 0x0003 ( 2), prologues 0, epilogues 1
*/
On Sun, 1 Jun 2008, Weddington, Eric wrote:
Hi Dr. John,
Are you using a particular WinAVR version? i.e. a patched avr-gcc 4.1.2?
Or is this stock FSF 4.1.2?
Can you post the compiler output?
Sorry, but most of the developers are dealing with HEAD/4.4 or maybe
4.3.0. I understand that you're using 4.1.2 for TinyOS.
Eric
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of John Regehr
Sent: Sunday, June 01, 2008 9:14 PM
To: avr-gcc-list@nongnu.org
Subject: [avr-gcc-list] wrong code from avr-gcc 4.1.2?
In the code below, avr-gcc 4.1.2 wants to return 1 from func_1() when
compiling at -Os. Specifically I'm compiling like this:
avr-gcc -fwrapv -Os -mmcu=atmega128 foo.c
I believe the correct answer is 0 (this is what avr-gcc-4.2.2
returns at
all optimization levels). I don't think the -fwrapv is relevant here
but include it to be on the safe side.
John Regehr
static inline unsigned long int
div_rhs(const long int rhs)
{
if (rhs == 0) return 1;
return rhs;
}
unsigned long g_66;
long g_73;
int func_1 (void)
{
unsigned long l_86 = -1L;
unsigned long l_93 = -9L;
if ((l_86 = g_73) (1 / div_rhs (l_93)))
return 1;
else
return 0;
}
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] wrong code from avr-gcc 4.1.2?
Sorry, but most of the developers are dealing with HEAD/4.4 or maybe 4.3.0. I understand that you're using 4.1.2 for TinyOS. Out of curiosity, what version of avr-gcc would you (and others) recommend right now for production use? Thanks, John ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] wrong code from avr-gcc 4.1.2?
Can you post the output using?: -O1 -dP
See below (but this isn't likely to be useful-- the function returns the
correct result at -O1). Code is wrong at -Os, -O2, and -O3. Even further
below is the compiler output for -Os -dP.
Thanks,
John
[EMAIL PROTECTED] tmp14]$ avr-gcc -O1 -dP -mmcu=atmega128 -fwrapv -S foo.c -o
-
.file foo.c
.arch atmega128
__SREG__ = 0x3f
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__tmp_reg__ = 0
__zero_reg__ = 1
.global __do_copy_data
.global __do_clear_bss
.text
.global func_1
.type func_1, @function
func_1:
/* prologue: frame size=0 */
/* prologue end (size=0) */
; (insn 16 9 22 (set (reg/i:HI 24 r24 [ result ])
; (const_int 0 [0x0])) 12 {*movhi} (nil)
; (nil))
ldi r24,lo8(0) ; 16 *movhi/4[length = 2]
ldi r25,hi8(0)
/* epilogue: frame size=0 */
ret
/* epilogue end (size=1) */
/* function func_1 size 3 (2) */
.size func_1, .-func_1
.comm g_66,4,1
.comm g_73,4,1
/* File foo.c: code3 = 0x0003 ( 2), prologues 0, epilogues 1
*/
[EMAIL PROTECTED] tmp14]$ avr-gcc -Os -dP -mmcu=atmega128 -fwrapv -S foo.c -o
-
.file foo.c
.arch atmega128
__SREG__ = 0x3f
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__tmp_reg__ = 0
__zero_reg__ = 1
.global __do_copy_data
.global __do_clear_bss
.text
.global func_1
.type func_1, @function
func_1:
/* prologue: frame size=0 */
/* prologue end (size=0) */
; (insn 16 9 22 (set (reg/i:HI 24 r24 [ result ])
; (const_int 1 [0x1])) 12 {*movhi} (nil)
; (nil))
ldi r24,lo8(1) ; 16 *movhi/4[length = 2]
ldi r25,hi8(1)
/* epilogue: frame size=0 */
ret
/* epilogue end (size=1) */
/* function func_1 size 3 (2) */
.size func_1, .-func_1
.comm g_66,4,1
.comm g_73,4,1
/* File foo.c: code3 = 0x0003 ( 2), prologues 0, epilogues 1
*/
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] even register number required
We found a bug in avr-gcc 4.1.2.
Thanks,
John Regehr
[EMAIL PROTECTED] tmp11]$ avr-gcc --version
avr-gcc (GCC) 4.1.2
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[EMAIL PROTECTED] tmp11]$ avr-gcc -Os -mmcu=atmega128 small.c
/tmp/ccHth5XR.s: Assembler messages:
/tmp/ccHth5XR.s:26: Error: even register number required
[EMAIL PROTECTED] tmp11]$ cat small.c
unsigned long g_45;
long
func_1 (void)
{
unsigned char l_76;
long l_88;
long l_83;
int tmp___30;
int __cil_tmp227;
long __cil_tmp229;
int __cil_tmp232;
int __cil_tmp233;
int __cil_tmp234;
__cil_tmp227 = rshift_s_u (l_88, 1);
__cil_tmp233 = rshift_s_u (l_83, __cil_tmp232);
__cil_tmp234 =
lshift_s_s (__cil_tmp229 ==
(long) ((unsigned long) tmp___30 =
((unsigned long) __cil_tmp233)),
(1868161115UL |
(g_45 | (unsigned long) (((long) 0) = __cil_tmp227))) ==
(unsigned long) l_76);
}
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] even register number required
To elaborate a bit, the problem boils down to generation of this clearly wrong code: movw r13,r24 John ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] even register number required
I just checked and 4.2.2 doesn't have the problem either. So probably not that big of a deal except that 4.1.2 is going to see fairly heavy use fairly shortly due to an upcoming TinyOS release. Thanks, John On Fri, 30 May 2008, Preston Wilson wrote: John Regehr wrote: We found a bug in avr-gcc 4.1.2. Thanks, John Regehr [EMAIL PROTECTED] tmp11]$ avr-gcc --version avr-gcc (GCC) 4.1.2 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [EMAIL PROTECTED] tmp11]$ avr-gcc -Os -mmcu=atmega128 small.c /tmp/ccHth5XR.s: Assembler messages: /tmp/ccHth5XR.s:26: Error: even register number required ... Just fyi this is not a problem with avr-gcc 4.3.0: $ avr-gcc --version avr-gcc.exe (WinAVR 20080512) 4.3.0 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I get no error when running avr-gcc -c -Os -mmcu=atmega128 small_test.c With $ avr-gcc --version avr-gcc.exe (GCC) 4.1.2 (WinAVR 20070525) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I get the same error you list. -Preston ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os
A few random facts: - accesses to volatiles without intervening sequence points may be reordered - accesses to volatiles with intervening sequence points may not be reordered - accesses to volatiles may be reordered with respect to non-side effecting operations (e.g. atan()) regardless of sequence points John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os
The PORTA bits are used for hardware control. I want to use the atan2(), etc. calls as pulse stretching. Then I recommend using the calls in util/delay.h to get exact delays instead of monkeying around with floating point routine calls. They'll be a lot more exact as well as being a boatlad smaller! Perhaps the atan2() call are accomplishing useful work... John ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os
Well, isn't the net effect of volatile simply a more fine-grained clobbering lock? Almost but not quite: - volatile says nothing about the atomicity of any given access - volatile does not suppress reordering (except with other volatiles) - volatile has no effect on caches and out-of-order memory subsystems (not an issue for AVR obviously) Basically volatile has the effect of sucking in programmers and then leaving them high and dry as system complexity increases. Also volatile is usually too fine-grained, ensuring consistency-always instead of what you want (consistency on lock release) and this can easily lead to inefficiencies. That's a counter-intuitive result. The No idea why. part makes me a little squinty-eyed. It certainly *could* be a generalizable result, but then again it might be an artifact of your code structure. Yep. My off-the-wall guess was that the clobbers reduced register pressure. I could not think of an easy way to test that hypothesis. Finally I'll just add a random plug for a piece of work that a colleague and I recently completed where we found that most compilers have problems implementing the volatile qualifier: http://www.cs.utah.edu/~regehr/papers/emsoft08_submit.pdf This is indeed bad news since (as we have seen so many times on this list) programmers have trouble with volatile too. Section 2 of our paper gives a fairly concise introduction to the semantics of volatile. John ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] AVR-Gcc and overflow behavior
Unsigned overflow is always OK. Signed overflow is undefined behavior (no better--in principle at least--than accessing beyond an array bound) unless you use the -fwrapv flag. John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] accessing carry bit
microcontroller compilers support - the ability to write things like if (CARRY) ... can be a big win for some code. A killer app for exposing some of the condition code flags to C may be that this facilitates very efficient integer over/under flow detection. Integer overflows are the source of many nasty security holes. John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] problem with malloc() in avr-libc 1.6.1
If you must use malloc() on an AVR, you should strongly consider writing some stub functions that permit your C code to compile on a PC platform where you can stress test it under observation of serious tools like Valgrind. My observation (from watching a few hundred students) is that debugging on an MCU is so hard that once you have added a few nasty pointer bugs into your code base, your chances of getting back to a totally reliable piece of software are not that good. Also in the code you sent, you did not check the return value from malloc() for null. On a small-memory platform this kind of check is not optional. John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] More results from the testsuite with avrtest
Please see the GCC project about this. IIRC, they already have a script that does a binary search on failing test cases. IIRC, it is in the contrib subdirectory. Also this Delta implementation is very useful for minimizing an offending test program (either before or after narrowing settling on a version of gcc): http://delta.tigris.org/ John ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: AVR Benchmark Test Suite [was: RE: [avr-gcc-list] GCC-AVRRegisteroptimisations]
Okaaayy. The Ohio one. Do you have link to what you mean? What, that wasn't clear enough??? Here's the link: http://selab.csuohio.edu/dsnrg/stack-estimator/ If you try it out I'd be interested to hear your experiences. My impression is that it needs just a bit of hacking before being really usable. John ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: AVR Benchmark Test Suite [was: RE: [avr-gcc-list]GCC-AVRRegisteroptimisations]
Is this program designed for general purpose AVR applications? Or just for TinyOS? The answer is unfortunately a bit subtle... The question is, how clever of an analysis do you want? This tool (and mine) attempt to be clever by inferring that at some program points, interrupts are disabled, which eliminates that possibility of that interrupt consuming extra stack RAM right there. Bill's tool exploits the fact that nesC guarantees that interrupts are disabled using specific function calls and also that these are lexically nested. An example of code that is does not have lexically nested critical sections is one where you call a function with interrupts enabled and it returns with interrupts disabled. You can do this if you want but few developers would do it on purpose. Anyway the upshot is that if you make the analysis a bit less clever (and therefore a bit less precise) Bill's tool should work fine on generic AVR codes. I'll ping him and see if he'll add an option that does this. Stack depth analysis should definitely be a part of an AVR test suite. It should also be in most developers' compilation toolchain but that's a different argument. John ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: AVR Benchmark Test Suite [was: RE: [avr-gcc-list] GCC-AVR Register optimisations]
I'll just plug Avrora again: http://compilers.cs.ucla.edu/avrora/ It runs on many platforms (written all in Java), is quite fast, and is well designed. Best of all it is easy to extend, you just add monitors that can be configured to receive a wide variety of callbacks about program events such as memory operations, I/O operations, execution of different kinds of instructions, interrupts, etc. focus on AVR-specific code, and GCC-specific AVR code at that. Definitely. If people want to test avr-gcc against other compilers, or compare AVR to other architectures, that's a separate exercise. MiBench is an aging but useful collection of embedded C codes: http://www.eecs.umich.edu/mibench/ John, I would welcome publicly available code from TinyOS, but I would need to be already compiled with nesc, so that way we just have straight C that we can feed into avr-gcc. Sure, this is easy. It'll target ATmega128 only, howver. Re. floating point I believe that the papabench codes do a lot of this: http://www.irit.fr/recherches/ARCHI/MARCH/rubrique.php3?id_rubrique=97 This is code extracted from the Paparazzi UAV project, which uses an ATmega for onboard flight control. There needs to be some consensus on what we measure, how we measure it, what output files we want generated, and hopefully some way to automatically generate composite results. I'm certainly open to anything in this area. Code size and static RAM consumption are obvious. Some sort of throughput metric is useful. For interrupt-driven codes, my group often uses processor duty cycle as a measure of efficiency. This is the % of time that the CPU is not in a sleep mode. Dyanmic stack memory consumption is good, though this is not a very consistent metric for interrupt-driven codes since in a short simulation run the worst-case stack usage is unlikely to be encountered. Perhaps adding up the stack memory usage of main + all interrupts would be better. John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: AVR Benchmark Test Suite [was: RE: [avr-gcc-list] GCC-AVR Register optimisations]
(A friend is currently tearing his hair out over a code size regression in a commercial PIC C compiler -- he needs to release a minor firmware update to the field... but not even the original code fits his flash any more...) Embedded compiler rule #1: If you find a version of the compiler that works, keep a copy around for the life of the product. John ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] odd left-shift behavior, avr-gcc 4.1.2
int32_t x = ((uint16_t)0xL) ((uint32_t)1L); puts 0xfffe into x, as opposed to 0x1fffe as I would have expected. Is a C compiler not required to promote such that both operands of a shift are the same size? Should have added: this was compiling for Mega128 and the behavior is robust across -O0, -O1, -O2, -Os, -O3. On the other hand, given the same input x86 gcc robustly puts 0x1fffe into x. John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] odd left-shift behavior, avr-gcc 4.1.2
The native int size on your x86 compiler is probably 32 bits. Each argument to the shift is promoted to int first; that's the bit about integer promotions and this gets you answer you're expecting. I believe the native int size on avr-gcc is 16 bits, so your left operand: ((uint16_t)0xL) stays at 16 bits on the AVR. Ok, thanks for bearing with me... I had been under the impression that shift requires both operands to have the same width (there are web pages that appear to say this), but a close read of the spec says that the result of a shift is the type of the promoted left operand. John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] odd left-shift behavior, avr-gcc 4.1.2
Using avr-gcc 4.1.2, this code: int32_t x = ((uint16_t)0xL) ((uint32_t)1L); puts 0xfffe into x, as opposed to 0x1fffe as I would have expected. Is a C compiler not required to promote such that both operands of a shift are the same size? Thanks, John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: TinyOs avr-gcc-4 - a wrap-up
Here's how I'd sum it up: - TinyOS is written in the nesC programming language, which is a close dialect of C supporting some additional features - At present there is only one compiler for the nesC language, and it operates by translating nesC input into C - The nesC language is designed to support easy interoperation with C code, either through direct inclusion or through linking - AVR was the original platform for TinyOS/nesC and is still an important one, although several other architectures are now supported John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Fwd: [Tinyos-help] TinyOs avr-gcc-4
A little more information for the gcc3 / gcc4 discussion: - for complicated TinyOS codes we get plenty of internal compiler errors from avr-gcc3 (the one distributed with TinyOS, I mean) - gcc3 has some abyssmally bad bugs regarding handling of volatiles that seem to be fixed in gcc4 - we have some good measurement infrastructure for AVR codes. I'll try to get one of my people to take the time to measure the CPU usage, code size, and stack memory usage of some TinyOS applications under avr-gcc3 and avr-gcc4 and then I'll post a comparison here. To the extent that TinyOS applications are typical of interrupt-driven ATmega codes, this may be of general interest. John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Fwd: [Tinyos-help] TinyOs avr-gcc-4
Eric I'm not an authority on this topic but here are my two cents: - nesC adds plenty of value beyond facilitating inlining, for example the component model, support for concurrency, generic components, network types, etc. - I see no reason why nesC/TinyOS cannot use the latest and greatest AVR toolchain. Probably it's mainly a matter of the TinyOS maintainers finding time for toolchain work. Also note that some TinyOS/nesC ports like msp430 are hopelessly mired in gcc3 for the foreseeable future. - David has spent a fair amount of effort on C interoperability for nesC programs. - nesC isn't that obscure, I think it can parse all of C. John Regehr On Mon, 15 Oct 2007, Eric Weddington wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of John Regehr Sent: Monday, October 15, 2007 12:42 PM To: David Gay Cc: Avr List Server Subject: Re: [avr-gcc-list] Fwd: [Tinyos-help] TinyOs avr-gcc-4 A little more information for the gcc3 / gcc4 discussion: - for complicated TinyOS codes we get plenty of internal compiler errors from avr-gcc3 (the one distributed with TinyOS, I mean) - gcc3 has some abyssmally bad bugs regarding handling of volatiles that seem to be fixed in gcc4 - we have some good measurement infrastructure for AVR codes. I'll try to get one of my people to take the time to measure the CPU usage, code size, and stack memory usage of some TinyOS applications under avr-gcc3 and avr-gcc4 and then I'll post a comparison here. To the extent that TinyOS applications are typical of interrupt-driven ATmega codes, this may be of general interest. John Regehr And just to add gasoline to the inferno: One of the main features of NesC is its ability to combine all source code modules and do cross-module optimization. This ability is now available in GCC 4.x with the -combine and -fwhole-program switches. This brings up the question about using NesC *at all* for TinyOS. Why can't TinyOS be recoded in C? There are certainly more engineers knowledgeable in C. If TinyOS were to be recoded in C, then: - This would allow better commercialization of embedded sensor network technology, mainly because the end-users designing applications do not have to learn an obscure academic language in order to use it. There are at least 3 companies that I know of that base part of their sensor network technology on TinyOS, that would suddenly have a more receptive market to their technology because it uses a standard language. - It would avoid fragmentation of the embedded sensor network academic community (re MantisOS, University of Colorado, Boulder). A cohesive community is one that is more able to go commercial. - It would allow the adoption of newer toolchains, with fixed bugs, new features, and more importantly newer devices. Atmel has an interest in seeing the sensor network community adopt newer processors with more RAM (for bigger applications), smaller flash (less cost), better power management, and those with newer capabilities that make these networking stacks easier to implement and use. And we have an interest in adding in capabilities for new radios. We can't easily help if NesC continues to use, and promote, a proprietary distribution of the AVR toolchain, and if TinyOS uses NesC. - It would also add even more people to the AVR toolchain community. As it stands if someone asks a TinyOS question on the avr-gcc-list (like how this thread gets started), we have to redirect them to the TinyOS group because the underlying code. We have people (students, usually) submit bug reports about uisp, and we keep repeating to them that uisp is no longer maintained, please use avrdude. If TinyOS used the latest AVR GCC toolchain, then there would be more people looking at the same set of toolchain bugs, and possibly coming up with ways to fix them or work around them. I've spoken with several stakeholders about this issue before (you know who you are). Other than the sheer engineering time and effort involved, why can't this be done? I see a lot of advantages for both sides of the fence. Eric Weddington Product Manager Atmel ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Problem with delay loop
Ah, ok then. In practice, I have never needed to use setjmp/longjmp, so I have a tendency to forget about these routines. We should all be so lucky :). John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Problem with delay loop
However, David brings up a good point. A local variable is put on the stack, generally not the place for hardware to modify the variable. And generally, other parts of the program (such as ISRs) don't have access to the specific location of the variable on the stack. Both hardware and ISRs work with global variables. So *could* a compiler reason that local variables could never be volatile? Or are there truly situations where hardware or ISRs could modify local variables on the stack? The common use of volatile automatic variables is in conjunction with setjmp/longjmp. This idiom would break if volatile locals went into registers. Also there's no reason (in principle) that interrupts cannot access stack frames of non-interrupt contexts. So anyway, I would say that regardless of what the standard actually says, it *should* specify that volatile locals behave similarly to volatile globals: loads and stores in the abstract machine must correspond one-to-one with loads and stores (to RAM, not registers) in the physical machine. John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] possible 4.1.2 bug
Hi all-
The code below, compiled with avr-gcc 4.1.2 like this
avr-gcc -c -Os -mmcu=atmega128 prob.c
produces faulty assembly code that attempts ldi into r14. I'm not at
all sure that the asm is correct (didn't write it) but it seems that gcc
shouldn't be picking an unusable register in any case. The only other
version I tried is 3.4.3 which has the same problem.
Figured I'd check here to see if I'm missing something silly before
filing a bug.
John Regehr
void foo (char, char, char, char, char);
short bar (void)
{
char a = 0;
volatile char b = 0;
char c = 0;
char d = 0;
char e = 0;
int in;
int out;
foo (e, d, c, b, a);
__asm__ (swap %B1 \n\t
swap %C1 \n\t
swap %D1 \n\t
ldi %A1, 0xf0 \n\t
eor %D1, %C1 \n\t
and %D1, %A1 \n\t
eor %D1, %C1 \n\t
eor %C1, %B1 \n\t
and %C1, %A1 \n\t
eor %C1, %B1 \n\t
movw %A0, %C1 \n\t
: =r (out) : r (in));
return out;
}
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] possible 4.1.2 bug
Doh. I figured that this sort of constraint would be implicit from the instructions used. Thanks! John Regehr On Thu, 29 Mar 2007, Joerg Wunsch wrote: John Regehr [EMAIL PROTECTED] wrote: I'm not at all sure that the asm is correct (didn't write it) but it seems that gcc shouldn't be picking an unusable register in any case. The constraint r says: You are free to pick *any* register. As your instruction requires an upper register (r16 through r31), you simply need to tell that: make the constraint of the second argument d, and it will work. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] avr-gcc 3.4.3 confused about function pointers
I'm attaching a program that avr-gcc 3.4.3 miscompiles. The bug is
nasty and results in indirect calls to neverneverland.
Compiling like this:
avr-gcc -Wall -mmcu=atmega128 -Os foo.c
gives a program that icalls to a bad address.
On the other hand, compiling the same program with -O instead of -Os
results in correct code.
The problem occurs when the Z register is loaded with the address of
foo(). In the buggy (-Os) version, the literal address of foo() is
loaded, rather than the address shifted right by one bit position. With
-O the compiler gets it right.
I'd appreciate hearing about it if there's a patch for this or if the
bug is known to be fixed in later versions.
Thanks,
John Regehr
struct bar
{
void *yyy;
void *aaa;
};
void foo (void)
{
}
void stuff (void)
{
struct bar back[2];
void (*p) (void) = foo;
back[0].aaa = (void *) (foo + 1);
int i;
for (i=0; i6; i++) {
back[0].aaa = back[0].yyy;
}
(*p)();
}
int
main (void)
{
stuff ();
return 0;
}
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
