[Top][All Lists]

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

Re: [avr-gcc-list] simulator

From: ChristoGeo
Subject: Re: [avr-gcc-list] simulator
Date: Mon, 01 Oct 2001 08:47:00 -0700

If written in C, it would run in any environment. I still use DOS and Linux. Dos is my majority of my time. I was trying to port one of my 6805 simulators into Linux (C), but I have some problems to resolve regarding a crash ;)


At 09:27 AM 10/1/2001 -0600, Theodore A. Roth wrote:
Hi Jason,

I haven't run any tests to see how many instructions per second it can do,
but I have already hooked in the python profiler and see that most of the
overhead is in initializing all the arrays for the device and dumping a
core image. The profiler seems to tell me it's not spending much time in
the actual instruction execution time. Things would be much faster for me
if I wasn't using a Dual Pentium Pro 180 system for development. I'm sure
it would be considerably faster with some of the gigahertz processors out
there now.

You're right that it's now going to be as fast as C/C++, but pythons hash
and array accesses are faster than most people think. It's the walking of
the hashes or arrays that is really slow as I'm seeing when I do core

I've already been giving thought to on/off-chip peripherals via a virtual
hardware interface. It's still a little weak in the kness, but I got the
basics of IO Port access done last night. I'm going to clean it up a bit
today and then will get it up on the web for others to see.

The flexibility and os independence of python are why I choose it. It is
also possible to put the bottle necks into C modules to speed things up if
necessary, although it makes it a bit harder to compile and run on many
platforms. I'm also game to just using this as a prototype for something
in pure C or C++.

Ted Roth

On Mon, 1 Oct 2001, Jason Kyle wrote:

:)Hi Ted,
:)What kind of simulation speed can you achieve?  I imagine using python
:)wouldn't be all that quick.  Whatever is finally included with gdb will
:)most definitely require as complete on-chip peripheral simulation as
:)possible as well as the ability to add off-chip devices (e.g. LCD display)
:)virtually wired to the virtual AVR.  Flexability will be the prime
:)requirement (that includes OS independence), speed secondary but important.
:)Anyone else got any thoughts on simulators?  Bruce?
:)Jason Kyle
:)avr-gcc-list mailing list

avr-gcc-list mailing list

reply via email to

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