[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] binutils/.../testsuite/avr

From: Erik Christiansen
Subject: Re: [avr-gcc-list] binutils/.../testsuite/avr
Date: Fri, 3 Dec 2004 14:56:24 +1100
User-agent: Mutt/1.5.6+20040722i

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.

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.

Looking in /usr/local/src/gcc-3.3/gcc/testsuite/gcc.misc-tests, for
comparison purposes, there seems to be xxx.c and xxx.exp file pairs,
where xxx.exp is a script for an engine testing expected behaviour. (Or
something like that.) If or how that could be leveraged for avr-gcc is a
possible next step, but the immediate goal is to perform regression
testing on the assembler.

Dmitry has sent me a single "test suite" comprising min and max cases
for each instruction, each accompanied by the correct hex values for its
opcode. An accompanying makefile assembles the file, and runs a C
program to verify the assembler output.

At the moment, I'm trying to understand what could be required, beyond
expanding the existing 245 instruction - operand combinations. Any
insight is gratefully accepted.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]