Re: [avr-gcc-list] testsuite saga continues

[Paulo Marques]

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."