simulavr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Simulavr-devel] simulavrxx timers


From: Michael N. Moran
Subject: Re: [Simulavr-devel] simulavrxx timers
Date: Tue, 27 May 2008 08:37:44 -0400
User-agent: Thunderbird 2.0.0.5 (X11/20070727)

Klaus Rudolph wrote:
My thought is to write global timer feature classes, e.g. output compare, and build nested timer classes from the feature classes.

A long time ago I thought that some more generic classes and inheritance could solve many problems. But after looking in the details this plan was knocked out.

It would be interesting to understand the specifics
about this decision. Does this mean that abstraction
is not an option and that each hardware element that
is different in some way must be re-written from
scratch?

To have to many switch/if inside the class for
specialization

IMHO, with few exceptions, switch statements in OO
languages (C++) are an abomination. Good OO should
be using polymorphism rather than switch statements.

costs to much runtime I think.

This statement bothers me. What is the standard/
requirement that defines "too much?"

Are we expecting the simulator to run at least 100%
"as fast" as *any* AVR? 150%? 50%? Including I/O
to the simulation environment?

For my simulation purposes, 50% for a modestly clocked
AVR seems more than reasonable, and easily achievable
with a modern host CPU.

The 68K/CPU32 simulator that I helped develop
executed faster than a real 16MHz CPU32 system and
used polymorphic C++ in the peripheral simulation
subsystem.

Beware of premature optimization.

But I have actually no experience with the newer avr's so
it is up to you to make a more general design for the newer devices.

Analyzing the many AVR peripheral variations and
developing a properly factored design is a real
time consumer.

If refactoring is applied as new devices are
implemented, a peripheral framework can evolve,
rather than being designed all at once. The code
will be volatile in the early stages, and eventually
converge. The volatility can be reduced by doing
more up-front analysis and design... a
basic engineering trade-off.

IMHO, its the active itch scratchers that decide.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
 and we never even know we have the key."
"Already Gone" by Jack Tempchin (recorded by The Eagles)

The Beatles were wrong: 1 & 1 & 1 is 1




reply via email to

[Prev in Thread] Current Thread [Next in Thread]