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

[Weddington, Eric]

> -----Original Message-----
> From: Paulo Marques [mailto:address@hidden 
> Sent: Saturday, January 12, 2008 8:21 AM
> To: Weddington, Eric
> Cc: Andrew Hutchinson; address@hidden; 
> address@hidden; address@hidden; Klaus Rudolph
> Subject: Re: Simulator for GCC Testing [was: RE: [Fwd: Re: 
> [avr-gcc-list]GCC-AVR Register optimisations]]
> 
> Quoting "Weddington, Eric" <address@hidden>:
> >
> > 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)

The goal is for both. Simulavr is already being used for testing the
compiler and for avr-libc.
 
> 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.).

So now we're talking about simulavr again. Simulavr is written in C and
can at least be built for Cygwin. But it's unmaintained. The goal is to
get simulavrxx working for Cygwin AND for running the GCC test suite.
 
> 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...

And this will further split the community.

Why can't we work together, instead of always separately?

Eric Weddington