On Thu, Dec 02, 2004 at 08:16:41AM -0700, E. Weddington wrote:
Please note that probably one of the reasons why there isn't an avr
testsuite
for binutils (and
gcc) is that there isn't a method to run it, i.e. where is there a
simulator
that works well enough
to run the test suite?
There's simulavr, it's successor: simulavrxx, avrora, and I think that's
about
it for (open source)
simulators. None of these are in a state that can run an automated
testsuite
(for either binutils
or gcc). I would think that this needs to be addressed first.
Sorry, why should simulavrxx not be able to run automated testsuites?
The simulator has an scripting interface (tcl/python/... all what swig can
generate!), it is able to read elf files
it executes code also with ram/ext-ram eeprom and flash configurations
also with nearly exact timing and results could also be generated like
interrupt statistics and a lot more. And the gdb interface is also still
alive
where all intermediate steps could be watched in detail also automated like
the regressin tests from Theodore show. What is missing for automated
testsuite? No problem to implement this. Please give me a detailed
requirement list
and I will implement this. (I hope the list not so long :-)))
For a faster comparion maybe a elf file write could help where the
ram/flash/eeprom is written out and could be compared again a given
file. If that is needed or any other add on or change, let me know.
This is where I further reveal a lack of familiarity with gnu toolchain
development conventions, I'm afraid. Given that it is the target cpu
that runs the code which the assembler has created, it would seem quite
sufficient to confirm that the assembler generates correct opcodes for
all legal input.
That is what the simulator is good for. Simply check the results of a run.
The way how the result was generated is not interesting and can differ
from according to compiler command line option. OK, for binutils it doesn´t
matter
because the same input kust result int the same output :-)