[Top][All Lists]

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

Re: [Fwd: Re: [avr-gcc-list] GCC-AVR Register optimisations]

From: Paulo Marques
Subject: Re: [Fwd: Re: [avr-gcc-list] GCC-AVR Register optimisations]
Date: Fri, 11 Jan 2008 13:29:20 +0000
User-agent: Thunderbird (X11/20070509)

Dave N6NZ wrote:
The test matrix deserves some thought. The same test might have different pass/fail criteria under different options. For example, imagine a suite of 10 tests. You might say 10/10 must show zero code growth under -Os, 7/10 show no speed degradation under -Os, the same 10 tests must show zero slow down for 10/10 under -O3, 6/10 no code growth under -O3. (Just an example, may not be realistic.)

One thing that might help us a lot here, is a "cooperative simulator".

Something along these lines:

- the simulator would be used to test gcc, so most hardware simulation could be ignored. The test code could be written to only use what the simulator offered.

- the simulator could have special "ports" to control output and generate statistics to test regressions. Something along these lines (for instance):

- mem address 0xFF is the control port. Writting 0xEn starts cycle counter 'n' and writing 0xFn stops cycle counter 'n' and outputs the result

- writing a value less than 0x20 to the control port stops the emulator and returns that as the emulator exit code

   - writing to address 0xFE sends data to standard output

   - reading from address 0xFE reads one byte from standard input

The possibilities for commands and emulator control from the actual code being executed are endless, and this is just a few ideas from the top of my head.

Writing a simulator like this is pretty easy (I've written one for the CPU on my watch [1]) because most of the work in doing an emulator is writing the hardware emulation part. The CPU is the easy part, especially with a CPU with such a regular instruction set.

With this emulator we could build test scripts that would run the generated code under the emulator and could compare cycle counts, code size, return values, etc.

The idea is to allow avr code to run almost as any other unix process. What do you guys think? Is it worth doing? (and I'm volunteering for the initial work, at least)

Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: +351 252 290600, Fax: +351 252 290601
Web: www.grupopie.com

"Anything is possible, unless it's not."

[1] http://sourceforge.net/projects/virtualdatalink/ and

reply via email to

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