> On Sun Apr 12 2:05 , "Weddington, Eric" sent: > > >> -----Original Message----- > >> From: > >> [email protected] > >> [mailto:simulavr-devel-bounces+eric.weddington=atmel....@nongn > >> u.org] On Behalf Of [email protected] > >> Sent: Saturday, April 11, 2009 7:48 PM > >> To: '' simulavr-devel @ nongnu . org ''; 'Michael N . Moran' > >> Subject: Re: [Simulavr-devel] Uniform the code > > > >> Eric's comment on speed suggests a vote against pointers. > >> I haven't noticed any votes for pointers. > > > >Please note that I am agnostic when it comes to > methods/algorithms; I'm not a > C++ programmer. But instead of having bickering on the list, > I suggest that it be > solved with scientific methods: code up the different ways to > do it, test each > one and see which method is the fastest. Numbers and > measurement should rule the > argument. > > The test shouldn't be too hard to run. > We already have an example of each. > We just need code that will run on both an atmega128 and a atmega48. > I'd be rather surprised if adding a layer of indirection > speeded up the simulation. > The question would be whether the slowdown was significant.
Something to keep in mind: simulavrxx will be used (eventually) to run the GCC Regression Test Suite, which contains thousands of tests. Even if there was a neglible slowdown, even only at simulavrxx startup (not just during simulation), it will be noticable in the aggregate when running this test suite. > Absent either a major surprise about speed or news about the > benefits of pointers, > we should aggregate cpu parts directly. > > Bickering? I'm just trying to stop it before it starts. ;-) _______________________________________________ Simulavr-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/simulavr-devel
