Re: [avr-gcc-list] Why are we using EICALL and EIJMP for AVR256?

You misunderstand. I said Wiki is misleading. Not that your solution for bootloader is wrong. For example: "So in fact *eicall* instruction with current avr-gcc cannot call a function in upper half flash." Whereas avr-gcc can indeed call functions anywhere. It is not possible to handle EI

Re: [avr-gcc-list] __builtin_constant_p for inline func args with -Os

Os is not inlining the function - since it believe it will cause code size to grow. You can find this out by using inline warning option -Winline However, you can FORCE a function to be inlined thus static inline void digitalWrite(uint8_t pin, uint8_t val) __attribute__((always_inline)); st

Re: [avr-gcc-list] AVR atmega128 GCC 4.3.3 Testresults comparision

27, 2009 2:47 AM To: Andy H Cc: avr-gcc-list@nongnu.org Subject: RE: [avr-gcc-list] AVR atmega128 GCC 4.3.3 Testresults comparision Try the files and simulator craeted as part of WINAVR http://winavr.cvs.sourceforge.net/viewvc/winavr/avrtest/ Edit some paths to match your filespace

Re: [avr-gcc-list] AVR atmega128 GCC 4.3.3 Testresults comparision

Try the files and simulator craeted as part of WINAVR http://winavr.cvs.sourceforge.net/viewvc/winavr/avrtest/ Edit some paths to match your filespace. Andy Boyapati, Anitha wrote: -Original Message- From: Weddington, Eric Sent: Saturday, October 24, 2009 5:32 AM To: Boyapati, A

[avr-gcc-list] Running testsuite

ake -k check RUNTESTFLAGS="--target_board=atmega128-sim -all" voila! Andy H wrote: Got it . 2.19 is ok. Does anyone have the dejagnu setup files - in particular the make check RUNTESTFLAGS settings to link correct exit.c and run avrtest. I have lost instructions! Andy Weddi

Re: [avr-gcc-list] Todays gcc build gives illegal opcode elpm for mcuavr5

=atmel@nongnu.org [mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu. org] On Behalf Of Andy H Sent: Saturday, September 12, 2009 6:33 PM To: avr-gcc-list@nongnu.org Subject: [avr-gcc-list] Todays gcc build gives illegal opcode elpm for mcuavr5 I'm reinstall gcc toolchain

[avr-gcc-list] Todays gcc build gives illegal opcode elpm for mcu avr5

I'm reinstall gcc toolchain under Linux from sources. This built from todays head version. I get : Error: illegal opcode elpm for mcu avr5 What am I doing wrong here with binutils versions? Or is this bug 35936 that Eric just closed. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35936 /home/a

Re: [avr-gcc-list] Transfer bit conserved by gcc?

Gcc only tests certain conditions and requires zero, carry and overflow sign flags to be set usefully (ie indicating result). The real AVR flag status is translated to a similar internal flag set within gcc. It does not use H flag or T flag. But certain sequences emitted by backend to synthes

[avr-gcc-list] Can someone benchmark this option please

Hi, I have noted problem where gcc is optimizing if-then-else constructs - with disastrous results. For example: if (a >= 0) return 8; else return 0; (This is now reported as bug.) Can folks try the following gcc option -fno-if-conversion on their own code at -Os optimization, and see if

[avr-gcc-list] Problems with skip patterns

Hi, Here is an issue I would like you to review. avr-gcc uses the SBRS and SBRC instruction to both test and branch for certain bit tests. Similary with I/O bits SBIC SBIS These were originally peephole optimizations that were converted to peephole2 optimizations (the latter produce RTL ra

Re: [avr-gcc-list] Re: "progmem_far" attribute

for 256K devices. My objection to far, was for Anatoly's patch - as this is only a separate space. So I suggested high/low or perhaps even upper/lower or space1/2. "far" normal means an attribute that allow access to any part of memory - eg big pointer. Jim Brain wrote

Re: [avr-gcc-list] Re: "progmem_far" attribute

Yes this should be more than enough for data! I am happy with "high" or anything that is not "far". (Its bad enough with "trampolines" that are not really trampolines.) ;-) Andy Anatoly Sokolov wrote: Hi. From: "Andy H" <[EMAIL PROTECTED]> Sent

Re: [avr-gcc-list] Re: "progmem_far" attribute

squark that it is not a pointer. Andy Bob Paddock wrote: On 7/20/08, Andy H <[EMAIL PROTECTED]> wrote: If we can create "FAR" as unsigned long Should that not be size_t rather than unsigned long? Might not make a difference on the smaller AVR's right now but if we

Re: [avr-gcc-list] Re: "progmem_far" attribute

To use that amount, would suggest we need additional abilities to access progmem without going thru RAM. But if this is considered a limitation then your method seems ok. A better name would be progmem_high. FAR is entirely different. FAR is normally used to indicate large pointers - not

Re: [avr-gcc-list] Copy uint32 to Memory optimization?!

This happens because the AVR backend of gcc defines RTL for wide mode instructions it does not have. So what you have here is a literal translation from a single RTL instruction into 8 assembler instructions. The compiler sees 1 instruction. And yes you are correct this produces sub-optimal c

Re: [avr-gcc-list] Checking carry flag and Rotate operation in C.

of a bug report or at least a place on the TODO list. Andy Andy H wrote: The simple answer us that you cant. Thougg we could do with this in library and/or gcc patterns (builtin rotate) This is close: unsigned char foo(unsigned char b) { if (b & 128) { b <<= 1; b ^= 0b00011101

Re: [avr-gcc-list] Checking carry flag and Rotate operation in C.

The simple answer us that you cant. Thougg we could do with this in library and/or gcc patterns (builtin rotate) This is close: unsigned char foo(unsigned char b) { if (b & 128) { b <<= 1; b ^= 0b00011101; } else { b<<=1; } return b; } unsigned char bar(unsigned char b) { if (b & 1

Re: [avr-gcc-list] Find problem with gcc patching libc

Just to confuse the issue! Andy Weddington, Eric wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Andy H Sent: Saturday, June 07, 2008 9:26 AM To: Mike Stein; [EMAIL PROTECTED]; avr-gcc-list@nongnu.org Subject: [avr-gcc-list] Find pr

[avr-gcc-list] Find problem with gcc patching libc

I was looking for cause of problem with Mike Steins tests setup, where stdio.h gets patched by gcc. This defines unused file functions but assume fpos_t is defined. Thus we get compilation failures. My cygwin and Debian linux setups dont have this problem. I have rebuilt my Debian setup with c

[avr-gcc-list] AVRtest wuth GCC

Another small problem with avrtest and testsuite. Version 1.3 had default cycle limit of 20. Latest version (and some between) have no limit. So dejagnu board file should be patched to specify command line instruction limit by adding -m switch set result [exec avrtest -m 1000

Re: [avr-gcc-list] Updates needed to AVR test files

-Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:avr-gcc- [EMAIL PROTECTED] Namens Andy H Verzonden: zondag 1 juni 2008 1:35 Aan: AVR-GCC; Paulo Marques; Mike Stein; Weddington, Eric; Anatoly Sokolov Onderwerp: Re: [avr-gcc-list] Updates needed to AVR test files Small typo - in

Re: [avr-gcc-list] Updates needed to AVR test files

Small typo - in COMPLEX_INT Should be set COMPAT_SKIPS [list {VA} {COMPLEX_INT}] not plural Duh! Andy Andy H wrote: BTW you can also just define these in environment and leave board file unchanged set COMPAT_SKIPS [list {VA} {COMPLEX_INTS}] set COMPAT_OPTIONS [list [list {-Os -mcall

Re: [avr-gcc-list] Updates needed to AVR test files

BTW you can also just define these in environment and leave board file unchanged set COMPAT_SKIPS [list {VA} {COMPLEX_INTS}] set COMPAT_OPTIONS [list [list {-Os -mcall-prologues} {-Os -mcall-prologues}]] Andy Andy H wrote: There are a couple of changes needed to AVR test files to pass a few

[avr-gcc-list] Updates needed to AVR test files

There are a couple of changes needed to AVR test files to pass a few tests. Compatibility tests default to no optimization and maximum tests - this can easily overflow 128K code area. Add these lines to end board file (mine is called atmega128-simnew.exp). They set environment vars that control

Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os

ly it's no better than doing the code inline, but it is more self-documenting. Hope this generates some more ideas/discussion, Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy H Sent: Thursday, May 22, 2008 5:36 PM To: David Brown Cc: avr

Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os

BTW I believe the common attribute/keyword for this should be monitor as in monitor void dostuff(void) { putchar ( ’Z’ ); } This will give a degree of compatibility with other compilers. David Brown wrote: [EMAIL PROTECTED] wrote: Eric, The problem with the function is typical housekeepin

Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os

http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Atomic-Builtins.html David Brown wrote: [EMAIL PROTECTED] wrote: Eric, The problem with the function is typical housekeeping overhead gets wrapped up. To take a silly example: Say you want to send some message to ISR (via memory) using critica

Re: [avr-gcc-list] Add builtins in avr target.

As before I disagree. But let Eric and users decide: 1) Should __builtin_return_address() be disable for 256K device. Since it will only return word not 3 bytes. 2) Should function pointer arithmetic be disabled for 256K device - since it will only operate on word address. I think answer s

[avr-gcc-list] Slight error in GCC instruction patterns

I'm posting this since I'll forget about it before I'll have time to post bug or patch in 2 weeks or so. I found bug/missed optimization in byte move patterns. Specfically, we miss the case than a load of zero to any register is as cheap as register to register move. Also that Q constrain memo

Re: [avr-gcc-list] the framepointer

Ruud, I glad you take the time to highlight problems. As you noted fomit-frame-pointer is not an absolute. For AVR the condition for elimination is stack slots > 0, calloc used and something I cant remember. What you see is stack slots >0. Again I'd have to study in detail to see why it wa

Re: [avr-gcc-list] the framepointer

Ruud The save around call will not use R18 upwards, as these are call clobbered. Lower registers require PUSH and POP. Without studying source and compiler RTL and optimisation level used I cannot say why it did not use a lower register. It may be the cost assumptions are not quite right for

Re: [avr-gcc-list] RE: Patch Fix PR35013, PR27192

because of gcc test base analysis or from an avr-gcc user's bug, but I suppose we would want a regression test if we don't have one. Thanks for you efforts! -dave Andy H wrote: I tested it with PROGMEM and it returns byte address (same as now) Tested it with Labels ( ptr = &&a

Re: [avr-gcc-list] the framepointer

Hi Ruud the source you refer to has assembler prolog/epilog. ie its old. The latest is written in RTL and does much better job of minimizing the code. (I have attached below) The frame pointer should only be used if it is needed. It will be omitted otherwise with fomit_frame_pointer. If st

Re: [avr-gcc-list] RE: Patch Fix PR35013, PR27192

I tested it with PROGMEM and it returns byte address (same as now) Tested it with Labels ( ptr = &&foo) and it return word address (which I intended). I did not test goto *ptr, as I have not loaded patch for jump/long jump (so its does nothing). I'm sure my patch for that expects words so it

Re: [avr-gcc-list] RE: Patch Fix PR35013, PR27192

I think I have found a simple fix. I changed gcc so that offsets added to assembler symbols are doubled. So in c when we use &foo+2 this gets send to assembler/linker as gs(foo+4). This has the effect that offsets or arithmetic are consistently in words - on a word pointer. (which makes mor

[avr-gcc-list] Re: Patch Fix PR35013, PR27192

RFC A problem has come up trying to fix function pointer arthmetic bugs. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35013 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27192 I created patch to solve this, but Anatoly has found a problem. Without patch we had &func returning word address an

Re: [avr-gcc-list] Add builtins in avr target.

Anatoly, __builtin_return_address is extremely useful for target error reporting. e.g. a function can be called(or trapped) to report error in another part of program. This allows such routines to determine the address of the caller without using naked asm functions. You are correct, that r

Re: [avr-gcc-list] Incorrect code by gcc?

nd others would have spotted it sooner. best regards and hope tulips look good. Andy Ruud Vlaming wrote: On Thursday 03 April 2008 00:27, Andy H wrote: Not a bug Very good spotting. Andy! Thank you! Thats the reason i wanted it to post here before sending in a bug report. Unfortu

Re: [avr-gcc-list] Incorrect code by gcc?

Not a bug According to the sources you posted, privQueuRequestBody void privQueuRequestBody(uint8_t uiSlot, int8_t siFreeFilling, uint16_t uiTicksToWait) __attribute__ ( ( naked ) ); The relevant part being "naked" That means gcc will omit prolog - which is where stack and frame pointer are

Re: [avr-gcc-list] RFC: Patch for "signal" argument

It's possible to have a target specific compilation flag that turns error into warning. Perhaps -no-error-but-warn-me-until-i-figure-it-out. ..or similar. Ron Kreymborg wrote: Can the "error" have overide? Might that be useful to permit code generation for a new variant before GCC has c

Re: [avr-gcc-list] memcpy

that should read -no-builtin-memcpy Andy H wrote: Try -*no*-*builtin-memcpy *on gcc command line. This should use library call instead of inline expansion. Inline expansion is quicker and not much bigger if you have optimization turned on.* Andy * David Kelly wrote: On Mar 29, 2008

Re: [avr-gcc-list] Coul you post patches?

Oops! forget 21080 - I fixed that one! Andy H wrote: Paulo, could you please post your testsuite patches on [EMAIL PROTECTED] - seeking approval. These cover incorrect tests that assume 32bit integers or 64bit floats. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35005 http://gcc.gnu.org

Re: [avr-gcc-list] memcpy

Try -*no*-*builtin-memcpy *on gcc command line. This should use library call instead of inline expansion. Inline expansion is quicker and not much bigger if you have optimization turned on.* Andy * David Kelly wrote: On Mar 29, 2008, at 4:58 AM, Wynand Weyers wrote: How do I get memcpy

[avr-gcc-list] Coul you post patches?

Paulo, could you please post your testsuite patches on [EMAIL PROTECTED] - seeking approval. These cover incorrect tests that assume 32bit integers or 64bit floats. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35005 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35163

[avr-gcc-list] Ways to fix gcc bug - builtin_return_address

Anatoly and others. Well the next bug on list of testsuite execute/torture failures for AVR is for gcc's builtin_return_address. This function is rarely used. But instead of ignoring it, it would be better to fix it, that change test to exclude AVR. Target is supposed to tell gcc the RTL ad

Re: [avr-gcc-list] (no subject)

sys/types.h - or the absence, does cause failure in gcc testsuite (missing include) when I run tests /execute/builtins. 100 or so failures - basically any test that ends in -chk. So I create blank copy :-) I have not figured out how gcc creates these includes and what method we might use to

Re: [avr-gcc-list] Error: illegal opcode movw for mcu avr3

Build from latest snapshot - it worked for me. And was quicker (no patches to mess with) Weddington, Eric wrote: -Original Message- From: FRANCISCO ESPINOLA [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 18, 2008 10:10 AM To: Weddington, Eric; avr-gcc-list@nongnu.org Subject:

Re: [avr-gcc-list] Re: AVR bug fix status

Also we need volunteer to run patches for regressions 1) AVR target - I just do execute/torture 2) 686 target - so that proof looks better on primary target I only have CYGWIN - which is way too slow for testsuite - I think it takes 2/3 hours for just torture/execute and it would not be better

Re: [avr-gcc-list] Bug35013 - Incomplete check for pm() annotation

Note that this bug is also related to: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27192 which has similar issue generating "byte address" instead of word address. Oddly my patch appears to fix that without problem, using : 45 0014 80E0 ldi r24,lo8(pm(foo+512)) 46 0016 90E0