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 :-)