Re: Simulator for GCC Testing [was: RE: [Fwd: Re: [avr-gcc-list] GCC-AVR Register optimisations]]

[Paulo Marques]

Quoting "Weddington, Eric" <address@hidden>:
> [...]>
> Hi All,

Hi,

> Some points:
>
> - Yes, GCC does have a Regression Test Suite, and it can execute for the
> AVR using the SimulAVR simulator. There are many, many tests that pass
> for the AVR. There are quite a few that don't, but most of those
> failures that I have looked at either the test needs fixing (because it
> assumes a 32-bit processor), or the tests don't apply to the AVR. Some
> work needs to be done to get the Regression Test Suite in shape for the
> AVR.
>
> - As mentioned, simulavr is known to work as a simulator for the GCC
> test suite. However, simulavr is not really maintained anymore. At the
> simulavr project on Savannah, there is a new code base called simulavrxx
> which is based on C++. This is maintained, but it could use help: It
> doesn't run on Cygwin yet, and AFAIK it cannot run the GCC Test Suite
> yet. Any help on this is deeply appreciated.
> <https://savannah.nongnu.org/projects/simulavr>
>
> I strongly recommend that the wheel not be reinvented. If people are
> interested in running the GCC Regression Test Suite, I would recommend
> using available tools, and improving the available tools rather then
> invent new ones.

I've looked at the code for both simulavr and simulavrxx. It seems to 
me that these are more geared towards people trying to debug problems 
with their own projects, and not so much automate compiler tests. (more 
like AVR studio, too)

Most of the code there is to handle all sorts of peripherals that can 
be found on avr microcontrollers, as is to be expected from full 
emulators. However, my idea is much simpler: it is probably just the 
size of "decoder.cpp" of simulavrxx, re-written in plain C. This should 
make it really easy to port it to any platform (cygwin, etc.).

The major advantage is that we are _not_ trying to emulate a specific 
avr model, and as such we can do all sorts of hacks to help the test / 
benchmark suite as best as we can.

We can allow the program to write to files on the host. We can measure 
acurate cycle timings and dump the results in a convenient way for the 
benchmark suite. We can emulate an AVR with 8Mb of flash and 2Mb of 
RAM. We can force the "start/stop cycle counter" instructions to use 
zero cycles, so that they don't interfere with the counts themselves. 
We can report exit codes from the avr code, so that the test suite can 
use it to determine success/failure in some of the tests. Etc., etc.

So, I don't think I'm reinventing the wheel here. This is getting to a 
point where I'm very tempted to just do it (it seems so simple) and 
publish it so that I can show what I mean...

--
Paulo Marques


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.