[avr-gcc-list] Improving bit manipulations in avr-gcc 4.x

74,23 @@ * config/i386/sse.md (sse5_pperm, sse5_pperm_pack_v2di_v4si, sse5_pperm_pack_v4si_v8hi, sse5_pperm_pack_v8hi_v16qi, sse5_perm): Fix constraints. + +2008-12-08 Georg-Johann Lay <[EMAIL PROTECTED]> + * config/avr/avr.md (*sbrx_branch_shiftrt, + *sbix_branch_shiftrt, + *ext

Re: [avr-gcc-list] Improving bit manipulations in avr-gcc 4.x

_v4si_v8hi, sse5_pperm_pack_v8hi_v16qi, sse5_perm): Fix constraints. + +2008-12-10 Georg-Johann Lay <[EMAIL PROTECTED]> + * config/avr/avr.md (adjust_len): New insn attribute to + prevent some insns' lengths to be altered by ADJUST_INSN_LENGTH. + * consig/avr/avr.c (adjust_insn_length): U

RE: [avr-gcc-list] Binding a register pair to a pointer

> register unsigned char counter asm ("r3") Pointers live in register pairs, you must not specify an odd number. However, I guess that specifying a GPR explicitly is not what you want? You can find some examples on the following page. The page is in german but the examples should give you some

Re: [avr-gcc-list] Improving bit manipulations in avr-gcc 4.x

Hi, please f'up to g...@gcc.gnu.org "[patch,avr]: Better support for single bit operations" http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00905.html Georg-Johann ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/

Re: [avr-gcc-list] Syntax: Function pointer hell... newbee lost ! ;-)

Vincent Trouilliez schrieb: Hi list, I need a little help from the pros ;-) I Googled for C tutorials on the net, found a few. They aren't all quite clear about how to use function pointers, and where they are clear, the syntax they suggest doesn't appear to work on avr-gcc :-( I need to call

Re: [avr-gcc-list] Using __tmp_reg__ etc in assembly file

Colin Wall schrieb: Hi List, I must be missing something. I can use symbols like __SREG__, __tmp_reg__ and __zero_reg__ in in-line asm (e.g. "push __tmp_reg__") but if I do the same in a pure assembly file, the compiler complains with "constant value required". How does one access these sym

Re: [avr-gcc-list] Using __tmp_reg__ etc in assembly file

Colin Wall schrieb: gcc gererates a header in easch assembly output that looks like .file "fifo.c" .arch atmega168 __SREG__ = 0x3f __SP_H__ = 0x3e __SP_L__ = 0x3d __tmp_reg__ = 0 __zero_reg__ = 1 .global __do_copy_data .global __do_clear_bss ; GNU C version 3.4.6 (avr) No, it does n

[avr-gcc-list] Where report ICE in WinAVR?

Hi, I just stumbled over this ICE in WinAVR 20081205: > internal compiler error: in propagate_rtx, at fwprop.c:469 and am unsure where to report it. The gcc bugzilla says that just bugs from official gcc releases should be reported there, but as far as I understand, WinWAR is a project on its

Re: [avr-gcc-list] Where report ICE in WinAVR?

Weddington, Eric schrieb: -Original Message- Hi, I just stumbled over this ICE in WinAVR 20081205: > internal compiler error: in propagate_rtx, at fwprop.c:469 So where shall I send the bug to? For an internal compiler error you can report it in either place: the GCC bug databas

Re: [avr-gcc-list] Where report ICE in WinAVR?

Weddington, Eric schrieb: Well, no wonder. Your test case shows this function: void put_sfrac16 (data16_t q) { unsigned char i; for (i=0; i < 2; i++) { register data16_t digit asm ("r24"); digit.asByte[1] = 0; digit.asByte[0] = q.asByte[0]; digit =

[avr-gcc-list] [patch] #18145: do not emit "__do_copy_data", "__do_clear_bss" if not needed

This is a fix for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18145 It takes into account .comm, .lcomm, .data, .data.*, .bss, .bss.* Georg-Johann avr-18145.patch Description: Binary data ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://

[avr-gcc-list] [patch]: insn attribute "adjust_len"

This patch introduces the new insn attribute "adjust_len". This attribute helps to keep track which insn (alternatives) need length adjustment and which don't need adjustment. There is no effect on the generated code or on the frontend etc (al least if it is describes correctly, otherwise the as

[avr-gcc-list] [patch] #27663: missed-optimization transforming a byte array to unsigned long

Hi, this patch soves the missed-optimization reported in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27663 to a certain degree. It works atop of the adjust_len insn attribute. With this patch it is the same trouble as with the 1-bit optimization stuff: Every single case of some algebra is han

Re: [avr-gcc-list] [patch] #18145: do not emit " __do_copy_data" , " __do_clear_bss" if not needed

> This is a fix for > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18145 > > It takes into account .comm, .lcomm, .data, .data.*, .bss, .bss.* > > Georg-Johann I implemented the .comm and .lcomm stuff as target functions as proposed by Anatoly. Georg-Johann avr-18145_v2.patch Descriptio

Re: RE: [avr-gcc-list] [patch] #27663: missed-optimization transforming abyte array to unsigned long

> Most of this patch has to do with using the "adjust_len" attribute and would > be better off in the adjust_len patch: Yes, I did this: > > BTW: How can I generate a patch against the mentioned > > "adjust_len insn attribute"?. I think that would be more handy? because I found no way to do th

Re: [avr-gcc-list] Problem With Call to Mulsi3

Thomas D. Dean schrieb: > I have code producing strange results. Hi. Your code looks strange, too ;-) > distance = =895*distance; [...] > 895*distance generates a call to __mulsi3, multiplying r25:22 by r21:18 > and returning the result in r25:22. > > However, I cannot find where r21

Re: [avr-gcc-list] introducing a new section in data memory

Weddington, Eric schrieb: -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 Parthasaradhi Nayani Sent: Thursday, February 19, 2009 11:37 AM To: avr-gcc-list Subject: [

Re: [avr-gcc-list] How to tell avr-gcc not to use some registers in the whole program?

Lin Nan schrieb: Hello, everyone! In my project, I need to bind four registers to two 16 bit pointers because the two pointers are used frequently. But I don't know exactly how to do it. Does anyone know something about it? You can do this by introducing two global register variables like r

Re: [avr-gcc-list] Newbie question

David VanHorn schrieb: :) Interrupt latency. I have an app on a Mega32L, running at 4 MHz. I'm trying to measure the widths of pulses that could be as short as 5uS. The theory was to detect the first rising edge, and zero T1. Then on the second rising edge, grab the count from T1, which is run

Re: [avr-gcc-list] Newbie question

David VanHorn schrieb: Use an input capture I/O bit and let the hardware take a snapshot of the timer value when the edge is detected. Zero latency as long as it doesn't occur faster than you can reset the input capture.. I looked at that, but I have two inputs. I don't see any way to use t

Re: [avr-gcc-list] Re: C vs. assembly performance

Nicholas Vinen schrieb: * On the other hand, it would be great if avr-gcc could perform some basic optimisations that even a fairly inexperienced amateur could manage. For example, things like "unsigned char x, y; x = y>>4" could use the nibble swap instruction rather than four shifts, and things

Re: [avr-gcc-list] Re: C vs. assembly performance

Nicholas Vinen schrieb: Georg-Johann Lay wrote: If you are sure it is really some performance issue/regression and not due to some language standard implication, you can add a report to http://sourceforge.net/tracker/?group_id=68108 so that the subject won't be forgotten. Also mind

Re: [avr-gcc-list] Re: C vs. assembly performance

Weddington, Eric schrieb: -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 Georg-Johann Lay Sent: Saturday, February 28, 2009 9:00 AM To: Nicholas Vinen Cc: avr-gcc

Re: [avr-gcc-list] Re: C vs. assembly performance

David Brown schrieb: Nicholas Vinen wrote: OK, I only spent a few minutes looking at old code and I found some obviously sub-optimal results. It distills down to this: #include int main(void) { unsigned long packet = 0; while(1) { if( !(PINC & _BV(PC2)) ) { packet = (packet<<

Re: [avr-gcc-list] Re: C vs. assembly performance

Vincent Trouilliez schrieb: On Sat, 28 Feb 2009 19:09:13 -0700 "Weddington, Eric" wrote: So in application code I tend to avoid switch statements for embedded systems, unless I'm writing throw-away code or the application is trivial. Oh no ! ;-) I have only recently got round to using switc

Re: [avr-gcc-list] Re: C vs. assembly performance

David Brown schrieb: variable names "tmp16", "tmp32" and "tmpS16" are truly awful. It is also (usually) best to declare such temporaries in as small a block as possible. Thus they should not be at the start of the function, but instead make your cases like this: {// (N * 0.75) - 40DB41

Re: [avr-gcc-list] Re: C vs. assembly performance

David Brown schrieb: Georg-Johann Lay wrote: As far as "the optimizer" of gcc is concerned, that makes no difference. It knows exactly what register contains what value and is aware of the place where a register "dies", i.e. the register can be reused for whatever other

Re: [avr-gcc-list] Re: C vs. assembly performance

David Brown schrieb: Georg-Johann Lay wrote: Source code structure is a concern of the project, not of the compiler. Even for braindead code that comes from a code generator a compiler is supposed to yield good results. That's true in theory - but embedded programmers are used t

Re: [avr-gcc-list] Re: C vs. assembly performance

David Brown schrieb: Georg-Johann Lay wrote: regardless if optimization is on or not. If fact I would guess that it is a policy that the code *must* be the same regardless what debug level (if any) or debug format is used, and code beeing dependent on debug level/format is worth a bug report

Re: [avr-gcc-list] Re: C vs. assembly performance

David Brown schrieb: I haven't looked at code generated for such switches (there is often so much of it), so I admit to having guessed a little. I was thinking especially of when you have debug information enabled - that can force the compiler to keep variables in separate registers. Accord

Re: [avr-gcc-list] Re: sprintf

David Brown schrieb: However, the compiler has a much better chance of doing bounds checking, alias checking, and other optimisations on the array expression. It is even free to reorganise the array, or keep it all in registers (I don't think any compilers do that, but maybe one day...), wher

Re: [avr-gcc-list] Re: Tables

David VanHorn schrieb: Speed is primary, I need to get the conversion absolutely as fast as possible. Accuracy is secondary. Once I have the logs, the rest of the calculation would be fixed point. My output will be a 16 bit binary value, the sum of N log values. My question comes down to wethe

Re: [avr-gcc-list] Any SimulAVR or avrtest users out there?

Weddington, Eric schrieb: Hi All, There's a lot of new work being done at the SimulAVR project: Specifically the "old" simulavr project hasn't had much maintenance done on it in years. There is an "avrtest" project (hosted at WinAVR) that is us

Re: [avr-gcc-list] Frame Layout, Stack Layout

Josef Eisl schrieb: > Hello, > > I recently tried to find out how the avr-gcc frame layout (stack layout) > looks like. I couldn't find any official documentation about this or is > there an *avr-gcc internals* manual I have not found yet? > I've created a figure [1] showing the stack after a CAL

[avr-gcc-list] Bug in *rotlsi3 insns?

Hi, im just browsing avr.md in trunk and stumbled over some new patterns that implement rotlsi3. IMHO, they are buggy. But I have no testcase to make it explicit. "*rotlsi3_8" splits for sched2 under the condition that ... && REGNO (operands[0]) != REGNO (operands[1]) Now suppose REGNO(op0)

Re: [avr-gcc-list] Bug in *rotlsi3 insns?

Georg-Johann Lay schrieb: Hi, im just browsing avr.md in trunk and stumbled over some new patterns that implement rotlsi3. IMHO, they are buggy. But I have no testcase to make it explicit. Consider this test case: unsigned long rotl (int dummy, unsigned long x) { return (x << 8

Re: [avr-gcc-list] Bug in *rotlsi3 insns?

Weddington, Eric schrieb: -Original Message- From: avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu. org] On Behalf Of Georg-Johann Lay Sent: Monday, March 23, 2009 1:49 PM To: avr-gcc-list@nongnu.org Subject

Re: [avr-gcc-list] Bug in *rotlsi3 insns?

Anatoly Sokolov schrieb: Hi. Consider this test case: unsigned long rotl (int dummy, unsigned long x) { return (x << 8) | (x >> 24); } Compile with, e.g. avr-gcc -mmcu=atmega8 -S -Os -fno-split-wide-types This will map 0x33221100 to 0x33110033 instead of to 0x22110033 Please test

[avr-gcc-list] [patch,avr-gcc] optimizing mov SI/SF

Hi, this patch is a minor optimization when moving a compile time const SI/SF to a reg that is not in LD_REGS. The patch tracks the value in the scratch register and saves some moves here and there. A small test program is attached to see the effect. Compile, e.g. with -Os -dp -S -Os -dp

[avr-gcc-list] Re: [patch,avr-gcc] optimizing mov SI/SF

Weddington, Eric schrieb: Hi Georg-Johann, What is the status of your FSF Copyright Assignment? For us to eventually incorporate your work, we would need to be able to commit it to GCC, which requires the copyright assignment. Hi Eric, D. Robertson from FSF wrote that he "will send me the pap

[avr-gcc-list] [WinAVR 20090313] Bug in split-Pattern for swap

Hi guys, in pass .166r.split1, avr-gcc makes a wrong transformation for the following testcase, compiled with -O: void g(unsigned char); void f1(unsigned x) { unsigned char y; y = (x >> 12) & 0x0F; g(y); } It deletes this insn (insn 8 20 9 2 foo.c:7 (set (reg:QI 24 r24

Re: [avr-gcc-list] Bug in *rotlsi3 insns?

Anatoly Sokolov schrieb: Hi. Consider this test case: unsigned long rotl (int dummy, unsigned long x) { return (x << 8) | (x >> 24); } Compile with, e.g. avr-gcc -mmcu=atmega8 -S -Os -fno-split-wide-types This will map 0x33221100 to 0x33110033 instead of to 0x22110033 Please test

Re: [avr-gcc-list] [WinAVR 20090313] Bug in split-Pattern for swap

Georg-Johann Lay schrieb: Hi guys, in pass .166r.split1, avr-gcc makes a wrong transformation for the following testcase, compiled with -O: void g(unsigned char); void f1(unsigned x) { unsigned char y; y = (x >> 12) & 0x0F; g(y); } To be more specific, I at

Re: [avr-gcc-list] [WinAVR 20090313] Bug in split-Pattern for swap

Weddington, Eric schrieb: It probably comes from the attached patch. This was a fix for GCC bug #11259: This was committed in 4.4. Eric Weddington Yes, that patch introduces the bug because operand0 resp. operand1 may be hard reg before re

Re: [avr-gcc-list] Code size 4.0.3 vs 4.3.3

Kang Tin LAI schrieb: Hi, My old code (a bootloader) compiled with 4.0.3 + avr-libc 1.4.4 the code size is 1068 bytes, but same code compiled with 4.3.3 + avr-libc 1.6.6 the code size is 1332 bytes! Optimization option is -Os, boot_page_xxx and boot_rww_xxx library functions are called only

Re: [avr-gcc-list] avr superoptimizer

Sean D'Epagnier schrieb: Hi, I posted a forum topic on a new avr superoptimizer I'm working on. It was noted that some people on this mailing list might be interested but don't view the forum regularly. The forum topic also contains the source code which you can download: http://www.avrfreaks.

Re: [avr-gcc-list] avr superoptimizer

Sean D'Epagnier schrieb: Hi, On 4/20/09, Georg-Johann Lay wrote: Hi Sean, as far as I understand, your tool runs on asm code, i.e. you map short sequences of asm instructions (which must not contain code labels) to other instruction sequences. Right, and it's far from complete.

Re: [avr-gcc-list] Optimisation of bit set/clear in uint32_t

Dale Whitfield schrieb: Hi, All this talk of super-optimisers, etc. brings this issue I've had, to the fore again. Perhaps there are suggestions on how to encourage the compiler to do the optimisations rather than having to hand-code to get the best result. There is some work which addresses

Re: [avr-gcc-list] avr superoptimizer

Sean D'Epagnier schrieb: If I can generate the RTL needed for multiple machines based only on the assembly, I will know what gcc is looking for. Also I can insert some kind of profiling or counter into the rtl and later remove all the rules gcc never uses. hmmm. I don't untestand what you mea

Re: [avr-gcc-list] Possible bug in avr-gcc 4.3.2?

Zoran Rilak schrieb: Hi all, I am fairly new to the world of uC programming. I've been using avr-gcc 4.3.2 with ATmega168 and stumbled upon something rather peculiar. Please consider the following code snippet (the crux of the matter is in the last block of code): No one will be able to help

[avr-gcc-list] Improvon 8*16 Multiplication

Moin guys, this little patch improves 16*8 multiplication to some degree. The FSF did'n yet send the assignment papers, but maybe the stuff is still useful all the same. cheers Georg-Johann Index: avr.md === --- avr.md (Revision

Re: [avr-gcc-list] Function Address fixup missing?

Stu Bell schrieb: The root of the problem is that GCC's architecture does not lend itself to 24-bit entities. As you noted, function pointers are 16 bits, which limits the range to 128K of flash (since all AVR instructions are 2 bytes wide, the program counter addresses 2 byte words). GCC coul

Re: [avr-gcc-list] no rule to make elf - error

Parthasaradhi Nayani schrieb: Hello all, I am using avr-gcc (WinAVR 20090313) 4.3.2 with PN - version v2.0.8.718-basie. When I create a project and try to compile a very simple file, I am getting make.exe: *** No rule to make target `test.c.elf', needed by `elf'. Stop. Can some one point ahy

Re: [avr-gcc-list] problem building gcc 4.3.2

Galen Seitz schrieb: Hi, I'm trying to build RHEL/CentOS packages that match the latest winavr release. I've downloaded Eric's patches and incorporated them into the build process. The build dies during libgcc with this error: Configuring in avr/libgcc configure: creating cache ./config.ca

Re: [avr-gcc-list] How can I find avr-libc/crt1/gcrt1.S ?

Dave Nadler schrieb: I need to review the startup code. IIUC, the source is avr-libc/crt1/gcrt1.S Its not in the WinAVR distribution I am using; only the compiled crtm128.o is included. Can anyone point me at this (or just email it to me) ? You mean this? http://www.nongnu.org/avr-libc/ __

Re: [avr-gcc-list] avr-gcc 4.5.1 doing bad reloads using X

Weddington, Eric schrieb: Thanks for doing this analysis! Would you also be willing to write up a GCC bug report for this? I'll see what we can do to get this fixed. Eric Weddington http://gcc.gnu.org/PR46278 Georg ___ AVR-GCC-list mailing list AV

Re: [avr-gcc-list] avr-libc-1.7.0 fails to compile

Weddington, Eric schrieb: currently working on a set of changes to avr-libc that should get it to build without the -k switch to make. - Please don't use gcc 4.5.1 for any real-world work. I've heard that there are bug reports against AVR GCC 4.5.x that need to get fixed. However, if you're u

Re: [avr-gcc-list] crosstool-NG

Weddington, Eric schrieb: avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org On Behalf Of Stu Bell Sent: Thursday, March 03, 2011 9:07 PM To: WinAVR is the Windows packaging of the AVR-GCC stuff, along with the avr-libc library. Along with some other stuff, too. ;-) (In addition, W

Re: [avr-gcc-list] crosstool-NG

Weddington, Eric schrieb: -Original Message- From: Omar Choudary I am on if I can help getting the tools together. As I proposed on the avr-freaks forum I would like to see avr-gcc + patches merging into the common gcc branch. Many patches cannot go into mainline GCC because their au

Re: [avr-gcc-list] crosstool-NG

Weddington, Eric schrieb: -Original Message- From: Georg-Johann Lay [mailto:a...@gjlay.de] Sent: Friday, March 04, 2011 10:37 AM To: Weddington, Eric Cc: Omar Choudary; avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] crosstool-NG Besides that, I was astonished that fixing bugs

Re: [avr-gcc-list] Re: crosstool-NG

David Brown schrieb: On 04/03/2011 06:20, Trevor Woerner wrote: On Thu, Mar 3, 2011 at 11:38 PM, Omar Choudary wrote: Trevor, your idea seems nice, although I would be even more enthusiastic to put all the patches into the mainstream gcc and then just do a normal cross-build for the tools.

Re: [avr-gcc-list] Re: an idea: adding serial sram to avr to extend heap storage

Raymond Moore schrieb: > On Sun, Mar 13, 2011 at 3:59 PM, David Brown wrote: >> On 13/03/11 19:01, John Myers wrote: >>> Hi Ray, >>> >>> It sounds like what you want is to create another address space. >>> There is the TR 18037 draft called "Programming Languages - C - >>> Extensions to support em

Re: [avr-gcc-list] AVR Group Definitions

Thomas D. Dean schrieb: I forgot, again... Where do I find the definitions of the AVR groupings? avr25 avr3 avr31 avr35 avr4 avr5 avr51 avr6 avrxmega3 avrxmega4 avrxmega5 avrxmega6 avrxmega7 The current fsf repository gives first hint: http://gcc.gnu.org/viewcvs/trunk/gcc/config/avr/avr-devi

Re: [avr-gcc-list] AVR Group Definitions

Thomas D. Dean schrieb: I have a group of .S files, library avrx2.6. I want to make a version of this library for each AVR group and install them in avr/lib/avrn, as appropriate. If I use 'make MCU=?', I get a list, including avr1, avr5, etc, as well as the known types like atmega128, etc.

[avr-gcc-list] Fixing PR44643 vs. PSTR macro

In order to fix gcc's PR44643, see http://gcc.gnu.org/PR44643 , I attached a proposed patch. At current, the problem is that avr.c:avr_insert_attributes() which implements targetm.insert_attributes sets TREE_READONLY to 1. This causes an assertion failure in c-typeck.c. The patch makes avr-gcc to

Re: [avr-gcc-list] Fixing PR44643 vs. PSTR macro

Joerg Wunsch schrieb: > Georg-Johann Lay wrote: > >> This means that at least PSTR in avr-libc from include/avr/pgmspace.h >> must be changed. >> >> The current avr-libc implementation of PSTR, however, reads >> >> #define PSTR(s) (__extension__({

Re: [avr-gcc-list] Fixing PR44643 vs. PSTR macro

Joerg Wunsch schrieb: > Georg-Johann Lay wrote: > >> Ok. But let me add that without changing PSTR as indicated and with >> PR44643 fixed as proposed, building avr-libc 1.6.8 resp. 1.7.1 will >> abort because avr-gcc errors on PSTR usage. > > It has been reporte

Re: [avr-gcc-list] Stack-allocated array bug

Cory Cross schrieb: > Hi all, > > I've been running into several problems with avr-gcc from the Debian > unstable repo which is at version 4.3.5. I am compiling for ATMega168. > This problem was also present going back to compilers from 2007. > > All the problems traced down to a stack-allocated

Re: [avr-gcc-list] Fixing PR44643 vs. PSTR macro

I now closed PR44643: http://gcc.gnu.org/PR44643 Note that to build avr-libc you will have to use the updated version of PSTR like #define PSTR(s) (__extension__({static const char __c[] PROGMEM = (s);&__c[0];})) With that PSTR avr-libc build again. Please f'up http://savannah.nongnu.org/bugs

[avr-gcc-list] Problems with avrtest simulator and avr-gcc testsuite.

With the avrtest simulator, I observe the following problem with the -m option (max instruction count): >avrtest var-expand2.exe -mmcu=avr51 -m 1019948 exit status: TIMEOUT reason: instruction count limit reached program: var-expand2.exe exit address: 000318 total cycles: 1483103 >av

Re: [avr-gcc-list] Problems with avrtest simulator and avr-gcc testsuite.

Georg-Johann Lay schrieb: > With the avrtest simulator, I observe the following problem with the > -m option (max instruction count): > >> avrtest var-expand2.exe -mmcu=avr51 -m 1019948 > > exit status: TIMEOUT > reason: instruction count limit reached >

Re: [avr-gcc-list] Problems with avrtest simulator and avr-gcc testsuite.

Paulo Marques schrieb: > Georg-Johann Lay wrote: >> Georg-Johann Lay schrieb: >>> With the avrtest simulator, I observe the following problem with the >>> -m option (max instruction count): >>> >>>> avrtest var-expand2.exe -mmcu=avr51 -m 10

Re: [avr-gcc-list] Problems with avrtest simulator and avr-gcc testsuite.

Paulo Marques schrieb: Georg-Johann Lay wrote: Paulo Marques schrieb: [...] Or maybe you are compiling the test suite for a cpu model that has RAM at those adresses? The last time I ran the test suite I was compiling for an atmega128 IIRC. A program that goes wild does such weird things

Re: [avr-gcc-list] Problems with avrtest simulatorand avr-gcc testsuite.

Paulo Marques schrieb: +/* avrtest counter wrappers */ + +static void start_perf_counter(int number) ... +static void stop_perf_counter(int number) ... static?? ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/li

Re: [avr-gcc-list] Problems with avrtest simulatorand avr-gcc testsuite.

Paulo Marques schrieb: > Georg-Johann Lay wrote: >> Paulo Marques schrieb: >> >>> +/* avrtest counter wrappers */ >>> + >>> +static void start_perf_counter(int number) >>> ... >>> +static void stop_perf_counter(int number) >>> .

Re: [avr-gcc-list] Strange Code generated when using Global Register Variables

Christian Steer schrieb: Hello list, // just to avoid optimizig: static volatile uint8_t tmp; You explicit inhibit optimization and expect to get good results? As your application is actually very small, I would propose to write it completely in assembly. valatile register is not suppo

Re: [avr-gcc-list] Strange Code generated when using Global Register Variables

Christian Steer schrieb: Hi, this is only a small example to demonstrate the compiled result. I do not expect good or small code from -O0, but for me it explains what the compiler is thinking: r24 is a storage location like ram, not able to perform calculations. If you like to understand what

Re: [avr-gcc-list] split movhi to 2 movqi

Ilya Lesokhin schrieb: Hi, I would like to split a movhi instruction from an immediate to a const address to 2 movqi instructions. (I'm using gcc 4.5.3 but i dont think it matters in this case) The current development version is 4.7.0. It won't help to provida a patch against an old version.

Re: [avr-gcc-list] split movhi to 2 movqi

Ilya Lesokhin schrieb: > i want to try to do it after the IRA phase, does anyone know if it makes > sence, and if so, is there a macro which tells me that i'm after that phase? reload_completed will tell you. You can use a splitter or a peephole, put neither of them looks tempting because handlin

Re: [avr-gcc-list] split movhi to 2 movqi

Ilya Lesokhin schrieb: > On Thu, May 19, 2011 at 6:43 PM, Georg-Johann Lay wrote: > >> Ilya Lesokhin schrieb: >> >> Hi, >>> I would like to split a movhi instruction from an immediate to a const >>> address to 2 movqi instructions. >>> (I&#x

Re: [avr-gcc-list] split movhi to 2 movqi

Ilya Lesokhin schrieb: >> That's because splitting a volatile mem is not appropriate. You would >> have to volatile QI accesses instead of one volatile HI access. This >> means the two parts could move far away from each other. GCC is >> conservative about volatiles, so should be a backend. >> >

Re: [avr-gcc-list] split movhi to 2 movqi

Ilya Lesokhin schrieb: it works great, thanks for all the help. though i have a few more questions and i'd be glad if you could answer them for me. 1. when and by whom adjust_insn_length(...) is called? See the sources in avr.h It's the implementation of a target macro. 2. to update my new

Re: [avr-gcc-list] Trunk broken for AVR Target?

Boyapati, Anitha schrieb: > > Hi, > > I am trying to build recent snapshot gcc-4.7-20110604 without any > patches. Build fails for libgcc2.c. Unless I am doing something > wrong, I think the trunk is broken. Can someone confirm this? > > --

Re: [avr-gcc-list] strange c++ obiect initialization problems (full code included)

Marcin S schrieb: > Hello there, > > from time to time i have a strange problems when initializing class > objects in file range by their respective constructors, i noted that > problem occurs only when that constructors takes pointers to other > global objects, tables or something else. > > What

[avr-gcc-list] Update of avrtest simulator

Hi, I just committed some changes to the avrtest simulator located at http://winavr.cvs.sourceforge.net/viewvc/winavr/avrtest/ The main changes are: * When running the avr-gcc testsuite, it is very much preferred to link against an object like exit-atmega128.o instead of compiling against a

Re: [avr-gcc-list] strange c++ obiect initialization problems (full code included)

Marcin S schrieb: 2011/6/9 Georg-Johann Lay : Marcin S schrieb: Hello there, from time to time i have a strange problems when initializing class objects in file range by their respective constructors, i noted that problem occurs only when that constructors takes pointers to other global

Re: [avr-gcc-list] strange c++ obiect initialization problems (full code included)

Marcin S schrieb: 2011/6/11 Georg-Johann Lay : Marcin S schrieb: 2011/6/9 Georg-Johann Lay : Marcin S schrieb: Hello there, from time to time i have a strange problems when initializing class objects in file range by their respective constructors, i noted that problem occurs only when

[avr-gcc-list] Trouble with: relocation truncated to fit: R_AVR_13_PCREL

Hi, running avr-gcc-4.7.0 testsuite I observe mentioned problem with the following command line: avr-gcc ./gcc/testsuite/gcc.c-torture/execute/980709-1.c -include stdlib.h -O2 -flto -flto-partition=none -mmcu=atmega128 -Wl,-u,vfprintf -lprintf_flt -Wl,-Tbss=0x802000,--defsym=__heap_end=0x80 -l

Re: [avr-gcc-list] Trouble with: relocation truncated tofit:R_AVR_13_PCREL

Boyapati, Anitha schrieb: > >> -Original Message- >> From: avr-gcc-list-bounces+anitha.boyapati=atmel@nongnu.org >> [mailto:avr-gcc-list-bounces+anitha.boyapati=atmel@nongnu.org] On >> Behalf Of Joerg Wunsch >> Sent: Thursday, June 16, 2011 11:30 AM >> To: avr-gcc-list@nongnu.org >

Re: [avr-gcc-list] Trouble with: relocation truncated to fit:R_AVR_13_PCREL

Boyapati, Anitha schrieb: >> The command line is a typical commandline used in testsuite regression >> test runs for avr-gcc. >> >> $avr-libc/libm/fplib/log.S shows explicit use of RCALL/RJMP to >> external symbols which should definitely not be there. >> > > 2. Can you attach log.S or paste relev

Re: [avr-gcc-list] AVR GDB testsuite

Boyapati, Anitha schrieb: Aah..I am already running into strange issues. Looks like these days GNU tools are waging a war against me :-( Now simulavr is complaining... if gcc -DHAVE_CONFIG_H -I. -I../../src -I.-Wall -Winline -Werror -I../../src/getopt -g -O2 -MT adc.o -MD -MP -MF ".deps/

Re: [avr-gcc-list] Compiling problem

John Tucker schrieb: I'm not even sure as to whether it's my compilation of avr-gcc that's causing the error or if it's something in the library. The error message I get while trying to compile avr-libc-1.7.1 is: --- ./../../libc/stdlib/dtostre.c: In

Re: [avr-gcc-list] Toolchain not showing up with xmega support

David L. Martin schrieb: > Built a new computer, installed Ubuntu 10.04.2 LTS. > > Rather than use the .deb packages, I figured I would roll up a toolchain > using these instructions: > http://www.nongnu.org/avr-libc/user-manual/install_tools.html > > Everything went well with the build, no error

Re: [avr-gcc-list] Toolchain not showing up with xmega support

Weddington, Eric schrieb: > >> There is no support for xmega in avr-gcc up to now, >> and I don't know if anyone intends to add it to, e.g., 4.7. > > Yes, I do. Hi Eric. What timeline? 4.7.0? The only difference from gcc perspective appears to be that SP can be changed atomically and SFR-offs

Re: [avr-gcc-list] AVR GDB testsuite

Joerg Wunsch schrieb: "Boyapati, Anitha" wrote: I know that avr-gdb can be run using simulavr as backend Someone (Georg-Johann?) recently told that the simulator that is built into GDB 7.x might also be worth a try. At first sight it looked promising, but when I tested code around avr-gcc

Re: [avr-gcc-list] AVR GDB testsuite

Paulo Marques schrieb: I don't know very well the details of the avr-libc testsuite, but from what I could understand I can see several things that would need to be done in order to use avrtest: [...] Humm... I looked at the test script and it seems it only uses the core dump file to "artistic

Re: [avr-gcc-list] Compile error libm.a/libc.a

Yigit Turgut wrote: > Hi, > > I have a full Slackware 13.37 x64 install and I am trying to make > Arduino work. I am receiving the following error when I try to > compile the code ; Please give the command line you used to call gcc together with -v. > /usr/lib/gcc/avr/4.4.4/../../../../avr/bin/

Re: [avr-gcc-list] Compile error libm.a/libc.a

ete compile / make / install > procedure, slackbuild makes sure of this in my experience. > > On Tue, Jul 12, 2011 at 1:46 PM, Georg-Johann Lay wrote: _^^^ Please don't quote email addresses in mailing lists! Thanks. >>

[avr-gcc-list] [avr-libc]: Smarter parity implementation

The current implementation of parity in avr-libc compiles #include #include uint8_t pari1 (uint8_t val) { return parity_even_bit (val); } with -Os to pari1: /* #APP */ mov __tmp_reg__,r24 swap r24 eor r24,__tmp_reg__ mov __tmp_reg__,r24 lsr r24

Re: [avr-gcc-list] [avr-libc]: Smarter parity implementation

Paulo Marques wrote: > Georg-Johann Lay wrote: >> The current implementation of parity in avr-libc compiles >> >> #include >> #include >> >> uint8_t pari1 (uint8_t val) >> { >> return parity_even_bit (val); >> } >> >&

  1   2   3   4   >