> -----Original Message----- > From: Paulo Marques [mailto:[EMAIL PROTECTED] > Sent: Saturday, January 12, 2008 8:21 AM > To: Weddington, Eric > Cc: Andrew Hutchinson; [EMAIL PROTECTED]; > [email protected]; [EMAIL PROTECTED]; Klaus Rudolph > Subject: Re: Simulator for GCC Testing [was: RE: [Fwd: Re: > [avr-gcc-list]GCC-AVR Register optimisations]] > > Quoting "Weddington, Eric" <[EMAIL PROTECTED]>: > > > > 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 _______________________________________________ AVR-GCC-list mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
