Its been a while since I played with this but I looked again at some of
the AVR GCC bugs
In particular 31786 - which is one example of where we get fatal error of :
error: unable to find a register to spill in class 'BASE_POINTER_REGS'
This is a nasty bug as it comes and goes with
Weddington, Eric wrote:
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of Andrew Hutchinson
Sent: Tuesday, January 01, 2008 1:11 PM
To: avr-gcc-list@nongnu.org
Subject: [avr-gcc-list] Bug 31786 spill in class 'BASE_POINTER_REGS
Here are changes.
Since Im using different GCC release (4.3 experimental) and have a few
debugging dump spots added, I cant give you a proper patch. But since
it only involves 3 lines I have listed it below:
Nothing crashed and no adverse code size problem on the stuff I tried.
It got
Hi
Does anyone have some code that creates tablejump in Avr-gcc? This is
where gcc will create table instead of long line of if-then-else tests
I cant seem to create enough switch cases to force one!
I have been looking at compilation patterns and noticed that gcc address
is multiplied by 2
Thanks!
This will work just fine. Seems all the attempts I made were too optimal!
Andy
Wouter van Gulik wrote:
I can make GCC use a jumptable using this code:
test.c
===
volatile int x;
volatile int y;
void foo (void) {
x++;
}
void main(void)
{
Hi all,
just spend some days going over gcc-avr and missed optimizations.
One area I looked at was register allocation - this is not gcc strong
point. However, the current settings we use are making life more
difficult than it needs be.
The current order is:
R24,25,\
18,19,\
20,21,\
GCC 4.0 introduced a register lowering pass that changes operations on
registers to the the lowest size required by the target (AVR) backend .
For example, 16 bit value that only has lower 8bits used should
(ideally) get lowered to just 8 bit operations .
This is potentially very significant
Here my input:
For starters gcc has testsuite that can be used. It's not perfect but
its quite demanding - even if we cant do all the tests.
Do we have info on setting this up with simulator? I did have some
instruction - once!
After than I suggest some benchmark that would produce more
I tried they earlier example:
char *p1 = x;
foo(p1++);
foo(p1++);
foo(p1++);
etc
Even with different register allocation, the result is bad.
a) Basic flow that gcc creates is something like:
b=a+1;
R24=a;
foo(R24);
c=b+1;
R24=b;
foo(R24)
This needs 1 variable to be saved over call.
or unimplemented
functions. Yet even with this functional regression can easily be seen.
Andy
Dave N6NZ wrote:
Andrew Hutchinson wrote:
Here my input:
For starters gcc has testsuite that can be used. It's not perfect but
its quite demanding - even if we cant do all the tests.
Yes, we could
I has resurrected my testsuite setup for AVR. Thanks Eric for emailling
me instructions.
I want to use this to check my patches.
The setup uses patched gcc files to run gcc tests thru the AVR-GCC
compiler. Using GDB and SIMULAVR for execution (if appropriate)
Now I'm running this under
Well I found one problem!
The illegal access to RAM was at address 0x1100 and 0x1101. Which I
mapped to give a test fail until I figured what it was.
AVRORA was correct as ATMEGA128 with internal memory only does not have
RAM here.
So I looked at bench mark and this one does a return from
While running testsuite with gcc 4.3 I have found that some standard
tests expect a return from main()
e.g.
int main()
{
blah blah
if(a==b) return 1;
return 0;
}
while others explicitly call abort() or exit(0)
The avr-gcc configuration I have built is creating a run-time JMP to
: Tuesday, January 15, 2008 5:01 PM
To: [EMAIL PROTECTED]
Cc: Weddington, Eric; Andrew Hutchinson; [EMAIL PROTECTED];
avr-gcc-list@nongnu.org; KlausRudolph
Subject: RE: Simulator for GCC Testing [was: RE: [Fwd:
Re:[avr-gcc-list]GCC-AVR Register optimisations]]
Quoting William Rivet [EMAIL
My build of gcc under windows (cygwin) give file size for cc1.exe of 22MB
Winavr is much smaller (200K).
Is this normal or do I need to strip files?
I was thinking 22MB is a lot to load from disk for testing.
Andy
___
AVR-GCC-list mailing
:[EMAIL PROTECTED]
Sent: Tuesday, January 15, 2008 5:01 PM
To: [EMAIL PROTECTED]
Cc: Weddington, Eric; Andrew Hutchinson; [EMAIL PROTECTED];
avr-gcc-list@nongnu.org; KlausRudolph
Subject: RE: Simulator for GCC Testing [was: RE: [Fwd:
Re:[avr-gcc-list]GCC-AVR Register optimisations]]
Quoting William
Great!
I assume you are running Linux? Or something is very wrong with my
setup! I get about 1/sec.
Think Cygwin struggles with all this - CPU is low on mine so it looks
like it just doesnt get enough timeslices.
I am looking to haul an old P3 together so I can run test suite on Linux.
I
to blame.
Andy
Erik Christiansen wrote:
On Fri, Jan 18, 2008 at 12:24:29AM -0500, Andrew Hutchinson wrote:
I think I have found a bug with avr register allocation.
Maybe not. ;-)
...
So R0 got trashed.
There will be other examples where this could happen as R0 is used is
quite a few
It is possible that you have optimization turned on - so gcc will put
variables into register.
Or, perhaps your code has used variables it did not need and gcc will
optimise them away.
For example:
int i
for (i=0;i1000;i++);
will dissappear.
-O0 (or optimisation 0) will stop this but code
The bug with PR27364 testcase appears recent.
It fails with my 4.3 experimental copy 13/12/2007
Ok with avr-gcc (GCC) 4.2.2 (WinAVR 20071221)
reduced testcase is:
long f2(long number_of_digits_to_use)
{
return ( number_of_digits_to_use * 11L ) ;
}
- created a sys/types.h with:
#include inttypes.h
#include stdint.h
where do I put new include file? (directory relative to prefix root)
I have updated my GCC to same rev as you.
Ok with ldflags changes
So hopefully I can re-run in sync with you.
Andy
Ok my latest build is squawking - I assume because my binutils is out of
step.
../../../../gcc/libgcc/../gcc/config/avr/libgcc.S:283: Error: illegal
opcode mov
w for mcu avr3
To make this painless, can someone please point me at correct sources
for binutils - and assocated patch set (one
Ok,
here are my test results - same GCC as Paulo - except I have install
some patches in avr to fix some reported bugs (hence I'm testing patches)
I did NOT include Paulo's testcase patch for
gcc.c-torture/execute/builtins/pr23484-chk.c: (Paulo please state
effect on numbers for this)
Here is my list:
FAIL: gcc.c-torture/execute/20010122-1.c execution, -O0
FAIL: gcc.c-torture/execute/20010122-1.c execution, -O1
FAIL: gcc.c-torture/execute/20010122-1.c execution, -O2
FAIL: gcc.c-torture/execute/20010122-1.c execution, -O3 -g
FAIL: gcc.c-torture/execute/20010122-1.c
That explains it!
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
I think you highlight the problem for gcc.
We are have to treat program memory as byte addressable to support LPM.
Direct, function calls only want word address to form the correct
opcode. But we use byte address labels and assembler removes the
redundant bit to form the correct opcode.
.
That does not explain the other problems reported directly. However
given foo is a function pointer, what is the type of the expression foo
+ 1.? Perhaps gcc treats such an expression as void?
Andy
Andrew Hutchinson wrote:
I think you highlight the problem for gcc.
We are have to treat
the same strange non equal
data/program space?
I know that the TI C54x series have a 8 bit program space, and a 16 bit data
space. sizeof(char) == sizeof(int), both 16-bit!, but instructions and
function addresses are in bytes
Maybe we can find some hints there?
HTH
Wouter
Andy
Andrew
There is a bug!
Backend (avr part) creates special pm() annotation by looking at RTL.
This is done in avr.c by this function:
static bool
avr_assemble_integer (rtx x, unsigned int size, int aligned_p)
{
debug_rtx(x); /*ADDED TO DEBUG*/
fprintf(stderr,size=%d align=%d\n\n,size,aligned_p);
gcc uses its own status register cc0 that is set as a result of
compares and operators such as EQ,LT,GT. This is effectively a
translation of the avr status register effects for signed/unsigned
operations. So after each instruction gcc know what status is available
or not.
This register
After updating avr to gcc head, I can no longer get correct startup file
for ATmega128. (cant find file) (crtm128.o?)
There have been changes to architecture - do I need to patch binutils or
something to get back in Sync?
atmega169 worked - but I forgot it only has 1K RAM so it failed
I posted patch to cure spill bugs. It passed all testing.
I would be interested in seeing how this affects size,speed of avr-gcc.
Changes should be minor, but please post any observations made.
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00040.html
Andy
:
-Original Message-
From: Andrew Hutchinson [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 16, 2008 2:47 PM
To: Weddington, Eric
Cc: Wouter van Gulik; avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] Bug35013 - Incomplete check for
pm() annotation
Thanks Eric
Eric,
can you get toolchain list updated?
There are various patches posted againt gcc problems but are not yet
listed. Also the following are missing:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34916
This is nasty bug that lies inside gcc. it's status needs to be elevated.
Also:
Here is status of the bugs I have looked at.
Bug status needs updating to status in Bugzilla
For example, confirm and update known to work/known to fail information.
I cannot do this.
Some of the bugs are serious and generally I would advise against using
4.3 - especially with long
get fixed.
Eric Weddington
-Original Message-
From: Andrew Hutchinson [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 16, 2008 10:06 AM
To: avr-gcc-list@nongnu.org; Weddington, Eric; Anatoly Sokolov
Subject: AVR bug fix status
Here is status of the bugs I have looked at.
Bug status
All,
I found old PC and got Debian loaded to help with testing instead of
Cygwin. Much to my amazement it worked - after I got the pre-requisite
packages loaded.
On a slower PC, it is about 10x faster at testing and a bit faster
building GCC. The shell stuff (including make) hurts Cygwin.
Unless the builtins expose more information to gcc, I cannot see any
benefit from the addins - with the possible exception of FMUL.
The result will be the same. No better code, no fewer bugs.
Yes there are lots of outstanding patches that fix real bugs. It would
seem to me that these are more
The patterns for AVR mega 256 use EICALL an EIJMP
Both require EIND to be set to provide upper address bits
However, we are using linker trampolines for both, so in either case the
16 bit jump or call is to the trampolines.
Are not the trampolines always located in first 128Kbytes? Thus we
addressing modes and a omission in call
patterns.
void (*fptr)();
fptr = main;
(*fptr)(); //Will use EICALL - should be CALL main
which become readily apparent with inlined code.
Andy
Sean D'Epagnier geckosena...@gmail.com wrote:
On 12/14/09, Andrew Hutchinson andrewhutchin
40 matches
Mail list logo
