RE: [Simulavr-devel] Uniform the code

[Weddington, Eric]

> On Sun Apr 12  2:05 , "Weddington, Eric"  sent:
> 
> >> -----Original Message-----
> >> From: 
> >> address@hidden 
> >> [mailto:address@hidden
> >> u.org] On Behalf Of address@hidden
> >> 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. ;-)