[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Simulator for GCC Testing [was: RE: [Fwd: Re: [avr-gcc-list]GCC-AVR
From: |
Paulo Marques |
Subject: |
RE: Simulator for GCC Testing [was: RE: [Fwd: Re: [avr-gcc-list]GCC-AVR Register optimisations]] |
Date: |
Sun, 13 Jan 2008 23:15:19 +0000 |
User-agent: |
Internet Messaging Program (IMP) H3 (4.1.2) |
Quoting "Weddington, Eric" <address@hidden>:
-----Original Message-----
[...]
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.
Yes, but simulavr isn't being maintained any more, right?
Even more, one of my points is that having a software to handle both
cases might be harder to maintain than a simple simulator and
full-featured hardware emulator as separate projects. This is not my
strongest point, though.
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.
No, simulavrxx has a _lot_ of code to handle peripherals. In fact it is
the majority of the code of simulavrxx. The CPU part is "just" 4897
lines out of a total of 20586.
[...]
And this will further split the community.
You make it sound like a bad thing.
Why can't we work together, instead of always separately?
Because it's not the way open source works. (or at least not the way it
works better)
Open source works the other way: projects blossom or die by natural
selection, with the advantage that we can pick the best parts of each
project and mix and match as we please (doing a bit of artificial
selection in the process).
So, I don't like the way simulavrxx works. The pre-decoding of flash
into instances of "opcode classes" doesn't seem like a good idea to me,
and it is a fundamental concept of simulavrxx. That _is_ my personal
opinion and everyone is entitled to his own.
Now, I don't mind at all discussing technical merits of the idea,
especially if I can show my own code to use as a counter argument. So,
I was trying to delay my replies (including the reply to Joerg Wunsch)
to a point where I could show some code instead of the natural
handwaving that these kinds of discussions inevitably degenerate into.
Attached is a beta version of avrtest. It also has a small "Hello,
World!" demo that actually runs under avrtest and produces the expected
output.
It is a single file of C code, 1391 lines long. It must still have some
bugs in there, but I was actually quite surprised when after writing
the whole thing it ran "Hello, World!" on the first attempt.
I used the "lookup_opcode" function from simulavrxx to save some time,
but if the author has a problem with me using it (although I'm legally
entitled to use it), I'll write my own too, because I believe that
respecting the author's whishes is more important than respecting the
actual license.
I'll be polishing it up a bit over the next few days because it still
lacks a few things:
- a few opcodes are still not implemented at all
- RAMPx registers still need to be handled in a few places
- a few hidden bugs (hopefully) that need to be chased down and shot
So, please, instead of just dismissing this project as a "vanity
hacker's project" or "NIH sindrome", just take a look at it. If you
still don't like it, that's fine. But at least now we can talk more
technical and less handwaving.
At least, I bet you can easily compile it under cygwin ;)
--
Paulo Marques
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
avrtest.tar.gz
Description: GNU Zip compressed data
- Re: [Fwd: Re: [avr-gcc-list] GCC-AVR Register optimisations], (continued)
- Simulator for GCC Testing [was: RE: [Fwd: Re: [avr-gcc-list] GCC-AVR Register optimisations]], Weddington, Eric, 2008/01/11
- Re: Simulator for GCC Testing [was: RE: [Fwd: Re: [avr-gcc-list] GCC-AVR Register optimisations]], Paulo Marques, 2008/01/12
- Re: Simulator for GCC Testing [was: RE: [Fwd: Re: [avr-gcc-list] GCC-AVR Register optimisations]], Gre7g Luterman, 2008/01/12
- Re: Simulator for GCC Testing [was: RE: [Fwd: Re: [avr-gcc-list] GCC-AVR Register optimisations]], Joerg Wunsch, 2008/01/12
- RE: Simulator for GCC Testing [was: RE: [Fwd: Re: [avr-gcc-list]GCC-AVR Register optimisations]], Weddington, Eric, 2008/01/13
- RE: Simulator for GCC Testing [was: RE: [Fwd: Re: [avr-gcc-list]GCC-AVR Register optimisations]],
Paulo Marques <=
- RE: Simulator for GCC Testing [was: RE: [Fwd: Re:[avr-gcc-list]GCC-AVR Register optimisations]], Weddington, Eric, 2008/01/13
- RE: Simulator for GCC Testing [was: RE: [Fwd: Re: [avr-gcc-list]GCC-AVR Register optimisations]], William Rivet, 2008/01/15
- RE: Simulator for GCC Testing [was: RE: [Fwd: Re: [avr-gcc-list]GCC-AVR Register optimisations]], Paulo Marques, 2008/01/15
- RE: Simulator for GCC Testing [was: RE: [Fwd: Re:[avr-gcc-list]GCC-AVR Register optimisations]], Weddington, Eric, 2008/01/15
- Re: Simulator for GCC Testing [was: RE: [Fwd: Re:[avr-gcc-list]GCC-AVR Register optimisations]], Andrew Hutchinson, 2008/01/15
- [avr-gcc-list] Cygwin GCC build cc1.exe file size, Andrew Hutchinson, 2008/01/15
- RE: [avr-gcc-list] Cygwin GCC build cc1.exe file size, Weddington, Eric, 2008/01/15
- Re: [avr-gcc-list] Cygwin GCC build cc1.exe file size, David Brown, 2008/01/16
- RE: [avr-gcc-list] Cygwin GCC build cc1.exe file size, Weddington, Eric, 2008/01/16
- [avr-gcc-list] GCC Testing, Andrew Hutchinson, 2008/01/15