[Top][All Lists]
[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
- [Simulavr-devel] simulavrxx timers, Michael Hennebry, 2008/05/26
- Re: [Simulavr-devel] simulavrxx timers, Klaus Rudolph, 2008/05/27
- Re: [Simulavr-devel] simulavrxx timers,
Michael N. Moran <=
- Re: [Simulavr-devel] simulavrxx timers, Michael Hennebry, 2008/05/27
- Re: [Simulavr-devel] simulavrxx timers, Michael Hennebry, 2008/05/30
- Re: [Simulavr-devel] simulavrxx timers, Klaus Rudolph, 2008/05/30
- Re: [Simulavr-devel] simulavrxx timers, Michael Hennebry, 2008/05/30
- Re: [Simulavr-devel] simulavrxx timers, Klaus Rudolph, 2008/05/30
- Re: [Simulavr-devel] simulavrxx timers, Michael Hennebry, 2008/05/30
- Re: [Simulavr-devel] simulavrxx timers, Michael Hennebry, 2008/05/31