The logging version will always be slower. This is not just a matter of
outputting the log, it is also a matter of building the log.
We can avoid the output cost by only printing the last N lines, but we
can not avoid the build cost. The code to do this was there at some
point, but I
Wouter van Gulik wrote:
Can you elaborate on that? What exactly are you calling a dump log?
Just printing out the last N instruction executed before the abort. so
it's easier to spot where the test fails, but not having the penalty of
running avrtest_log. Which on my windows machine is much
Hi, all
Wouter van Gulik wrote:
The exit through the exit port already shows the address. Its only
the exit through rjmp +0 that doesn't. I'll change that to make it
consistent.
On exit you print CPU_C while in log you print CPU_C * 2. That's the
difference, and CPU_C is not so useful.
Just a little note to let you know that the above change and other small
cleanups have been committed to cvs.
From the changelog:
- give more information at program exit
- cleanup a lot of #ifdef's
- change the timeout from cycles to instructions, because the simulator
runs slightly
Wouter van Gulik wrote:
[...]
The next step will definitely be ELF loading support. With ELF loading,
I can decode symbols like __bss_end to know where the stack overflows
exactly or use __stack to know where the stack underflows. I can also
do a more symbolic log, by decoding addresses to their
Wouter van Gulik wrote:
Paulo Marques schreef:
The program used more than 4k of stack? Yikes!
Well I thinks it's the 64 bit stack bug... if anything goes wrong with
the stack you might end up having a huge stack. It's a bug in the program.
That makes sense.
Can you make avrtest check on
Wouter van Gulik wrote:
The exit through the exit port already shows the address. Its only
the exit through rjmp +0 that doesn't. I'll change that to make it
consistent.
On exit you print CPU_C while in log you print CPU_C * 2. That's the
difference, and CPU_C is not so useful. Having the
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
Andrew Hutchinson schreef:
One might argue that carry is the result of a compare with largest
integer value (255 for bytes). But these situation do not directly arise
in C - or I assume any other supported language - so it is not
considered. (Though the ability to propage carry would indeed
In the meantime, I tried to not mark long long as unsupported, with
similar results.
Without no_long_long there are more 32 tests that fail, but less 556
tests are marked as unsupported. Which means that 64 bit long long's
are mostly supported in fact.
The question is: are long long's
Quoting Wouter van Gulik [EMAIL PROTECTED]:
[...]
BTW: 64 bit long long is really hard for a 8 bit microcontroller. At
least one of the tests (with -O0 optimization) was initially failing
from timeout, which means that it was taking more than 500 million
cycles to execute. Increasing the
Paulo Marques schreef:
The program used more than 4k of stack? Yikes!
Well I thinks it's the 64 bit stack bug... if anything goes wrong with
the stack you might end up having a huge stack. It's a bug in the program.
Can you make avrtest check on stack overflow?
I can, specially if I
Wouter van Gulik wrote:
Well, the GCC library provides most (if not all) functions for 64-bit
operations. Alas this is written in C and the compiler can't make this
nearly as good as an handwritten assembler routine. Mostly due to the lack
of carry support in gcc.
Is it feasible to introduce
I have not dug enough into the details of gcc, but I thought that flags
were only visible at a low level, such as in the avr.md file, where you
are defining the assembly code sequences for different effects. Thus it
is possible to define a 16-bit addition instruction with an add, adc
Wouter van Gulik wrote:
Yes this is exactly what I wanted to point out. The carry is now only
used in handwritten assembler (in avr.md). GCC's RTL does not know
anything about the carry bit being available when it's set/cleared and
when it's clobbered.
Is there some limitation in the RTL
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
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of Andrew Hutchinson
Sent: Wednesday, January 30, 2008 3:55 PM
To: Wouter van Gulik
Cc: avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] testsuite saga continues
gcc uses its own status
Quoting Wouter van Gulik [EMAIL PROTECTED]:
[...]
Do you have a clue on why the tests fail? There is an ugly bug concerning
stack allocation and 64 bit variables, maybe that is the evil one. See:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27386 for details.
All the failed tests I've seen so
18 matches
Mail list logo
