Re: [Simulavr-devel] SimulAVR + simulated hardware

[Bill]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Well, I cna't 'help myself...I'll add my  "me too" non-vote (who's
counting the votes after all? ;-) on this one.

I'm swamped learning all the tools I feel I'll need to do what I want
and cannot see myself contributing code to simulavr as it stands
becuase it really doesn't have a solid object-modelyet. There are many
pieces that are pretty well coded and modular, but there are enough
things that strike me as truly bizarre(sometimes unnecessary,
sometimes inefficient, inflexible or error-prone in ways that have
well understood solutions). If the C-code were at least object-based
(i.e. opaque data types, structure members manipulated via accessor
functions that are not considered "private" to a given "object") I
might be more willing to try to understand the code and contribute
directly. As it stands now, I'm more interested in the API of how to
interface simulavr to the outside world...i.e. so that simulavr might
be able to talk to my simulation and perhaps even hook up to a SID
simiulation. But then again, I'm also baffled by some of TR's
statments....maybe I'm just not savvy enough to "get it"...Why in the
world would he not use CVS to distribute his work in progress? Doesn't
CVS support tags and branches? I know tags are supported, which would
be enough to cover here...but I digress...he is managing as he sees
fit and it's easy to armchair-quarterback these things...

I must also point out that I hope T Roth doesn't take this the wrong
way. I greatly appreciate his efforts in the AVR tools. (I know he is
also involved with avr-libc) I really think that he and at least a few
of us are coming at this from different angles... It is also worth
noting that C does have benefits over C++ when it comes to combining
software packages....C++ does not yet have an ABI (there are drafts,
to be sure, which is good enough for me), there is no standard way to
manage template instantiation, etc.,  so you have real problems when
trying to mix and match libraries produced by different vendors,
etc...so a C interface even to a C++ version of simulavr might be
required anyway... Personally, I think the benefits far outweigh these
issues, which are being addressed by other groups. (and in practice,
most of these issues don't get in the way much to begin with)

As for efficiency, keep in mind that C++ can meet, and in some cases
exceed, even Fortran in it's own field of number-crunching. (google
kai C++ fortran benchmark for various papers/reports) I've used C++ to
manage memory mapped ports on our embedded system. The naive approach
indeed is slower than what you would do with hand-generated
assembler....applying a very simple template technique, the code
generated by our C++ compiler was nearly identical to what we would
have coded by hand, but since it was C++, it participates fully in our
C++ object models, participating in inline-expansions and
optimizations. I do think it is absolutely necessary to use templates
effectively(think generic programming and/or template metaprogramming)
to squeeze every last drop of performance out of C++. (and it makes
the resulting code bulletproof compared to the equivalent hand-coded
C) If performance is not of utmost performance, then you will likely
opt for more genericity, etc... Everything is a trade-off.  Of course
these more advanced techniques require a compiler that is up to the
task, many compilers are not standard compliant or don't implement the
template facilities as well as one would like.

Anyway, I'm trying to avoid reinventing the wheels here, so I'm trying
to move forward with SID and Klaus' work (based of course on TR's work!)

Bruce R'. Miller wrote:

| On Sunday 04 January 2004 04:58, Klaus Rudolph wrote:
|
|> Hi list,
|>
|> A happy new year to all members and thanks for the work in the
|> past.
|>
|> Again I read here that there is a need for a more completed
|> simulator. As I wrote a long time ago (last summer I think) I
|> have reimplemented the simulavr in c++ and added some
|> functionality which is actually requested in this thread here. So
|> I offer my work again here and give you a actual state of my
|> work, if the team is interested in :-)
|
|
| Klaus,
|
| When i first used Simulavr a while back there were a number of
features that I
| wanted to implement.  Unfortunately the code is writen in the
| ancient C language and every time I went to make a change I had to
| figure out
how to
| work around the deficiencies in the language.  I have become
| spoiled
by C++.
| Don't get me wrong here; I'm no candy-assed Java programmer.  I've
spent most
| of my career writting in assembler, BLISS-32 and C.  I've spent the
| last three years working in C++ on embedded systems.  It permits me
| to do
a lot of
| things that C is simply not expressive enough to do in a
| reaasonably
small
| amount of space.  Every time I thought of something to change I was
|
stymied
| by C.  Not that it couldn't be done in C.  It just didn't seem to
| be
worth
| the effort to change half a dozen files when I would only need to
make one
| change in a single C++ module.  This sort of project (large,
| modular,
many
| contributors) simply screams for C++.  You can see where Ted is
simulating a
| virtual object system.  Why not just do it in C++ and get the
| benefit
of the
| compiler's syntax checking?  A lot of people seem to have the
| mistaken impression that C++ is bloated and inefficient.  They must
| be thinking of Java.  C++ is more efficient than C in that it is
| more expressive and
this
| allows the optimizer to do a better job.  Some people argue that
| C++ has extra overheaad for virtual function calls.  Sure, if you
| use them;
you don't
| have to.  If you try to simulate them in C you will be even less
efficient.
|
| I appreciate that Ted wants to stick with C because so many
programmers are
| familiar with it.  I just wanted to throw in my vote, along with
yours, for
| C++.
|
| -b
|
|
| _______________________________________________ Simulavr-devel
| mailing list address@hidden
| http://mail.nongnu.org/mailman/listinfo/simulavr-devel
|

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFABinJuZBxYuVmoeoRAtpYAJ0Qdu7TIwsRvyW+/Kb51sK+QYBhFQCgm7pc
FlLb/ILx+9vxtukzYa3ukBA=
=vfsj
-----END PGP SIGNATURE-----