Paulo Marques <[EMAIL PROTECTED]> wrote: > 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)
No, that's one of their points but not the only one. simulavr is already in use by the avr-libc project for teir own testsuite, and as Eric told you, it used to be in use for the GCC testsuite as well. This is done by using the simulator on a standalone basis (as opposed to coupling it to GDB as it's the case for interactive debugging). I don't think another simulator will do any good. My opinion is that simulavrxx particularly needs help on the documentation front (the original author isn't very fluent in writing English), and it might need some help in upgrading some of the implemented features for more recent AVRs (but except for adding the ATmega256x architecture, this is not much of relevance for plain compiler or library tests). Another simulator will only further split the development forces rather than bundle them, it will further confuse the users about why there's a multitude of simulators (with none of them being really good), it will introduce further bugs rather than fixing those that are already there. Some of the CPU details are not so obvious from the datasheet, so since a further simulator is likely to ignore all the experience the other simulator writers have already collected, it stands a good chance of simulating wrong in some situations. Excuse me, but it sounds much like a vanity hacker's project to me than any serious help. NIH, so to speak. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) _______________________________________________ AVR-GCC-list mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
