[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] testsuite saga continues
From: |
Paulo Marques |
Subject: |
Re: [avr-gcc-list] testsuite saga continues |
Date: |
Fri, 01 Feb 2008 13:27:49 +0000 |
User-agent: |
Thunderbird 1.5.0.12 (X11/20070509) |
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 "true" address makes
referencing back into a .lss file easier.
Ah! Ok, that's easy to fix.
Also, one of the things that I still want to develop is reading the ELF
file directly. At that point I can read the symbol information too, and
give an even better log output, by converting addresses to symbols, not
only in data accesses, but also in function calls, exit addresses, etc.
And the total number of cycles past.
The latest version in CVS already does that. Just use:
Oops missed that change, I thought it was just speed update. And now it
also has more readable logs. Keep up the good work!
Thanks :)
[...]
BTW, Andrew sent me a test case he tried in both avrora and avrtest
and the total cycle count matched almost exactly: 7934 cycles for
avrora, 7935 cycles for avrtest. I bet the one cycle difference is
from the last OUT instruction, that avrora simply "breaks" before
executing it, while avrtest actually "executes" it.
This makes me think, can't we make the BREAK OPC code the exit code?
This will make it absolutely impossible to exit while writing to (the
wrong) memory. Now any write to the exit code memory location can end
the program.
Point is BREAK is probably not supported for other architectures?
I thought about that too, but it seemed harder to write the "exit"
function in C.
I've been thinking about writing an "avrtest.h" include file that has
all the wrappers for avrtest. This will include the cycle counting
functions and abort/exit.
At this point it should be easy enough to change the exit to a break opcode.
I don't think that we will have problems with different architectures.
In the worst case, we can always "emit" the binary opcode for the
"break" instruction and we can allow avrtest to execute it always,
independently of the architecture.
Have you tried the testsuite with a different architecture already?
Right now, there is no support in avrtest to specify the architecture
and disallow opcodes based on that.
On top of that, fixing the tests that fail on even the "most powerful"
avr's seems to be more high priority than getting other tests to start
failing because of resource limitations on the less powerful ones ;)
--
Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: +351 252 290600, Fax: +351 252 290601
Web: www.grupopie.com
"Very funny Scotty. Now beam up my clothes."
- Re: [avr-gcc-list] testsuite saga continues, Wouter van Gulik, 2008/02/01
- Re: [avr-gcc-list] testsuite saga continues, Paulo Marques, 2008/02/01
- Re: [avr-gcc-list] testsuite saga continues, Wouter van Gulik, 2008/02/01
- Re: [avr-gcc-list] testsuite saga continues,
Paulo Marques <=
- Re: [avr-gcc-list] testsuite saga continues, Andrew Hutchinson, 2008/02/01
- Re: [avr-gcc-list] testsuite saga continues, Paulo Marques, 2008/02/04
- RE: [avr-gcc-list] testsuite saga continues, Wouter van Gulik, 2008/02/04
- Re: [avr-gcc-list] testsuite saga continues, Paulo Marques, 2008/02/04
- Message not available
- Re: [avr-gcc-list] testsuite saga continues, Paulo Marques, 2008/02/07
- RE: [avr-gcc-list] testsuite saga continues, Wouter van Gulik, 2008/02/07
- Re: [avr-gcc-list] testsuite saga continues, Paulo Marques, 2008/02/07