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
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));
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
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,
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
=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 under
!
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
Weddington, Eric wrote:
-Original Message-
From: avr-gcc-list-bounces
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
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
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
this and not 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 ever need to port
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: Sunday, July 20, 2008 8:51 PM
A better name
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
, it will produce code using shifts. I think this is worthy 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
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 128)
{
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
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 problem
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
-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
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
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
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
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
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
-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-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] Avr-gcc Produces Incorrect
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
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
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
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
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
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
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
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.
Unfortunately i already did so
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
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
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
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
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
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
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
40 matches
Mail list logo
