simulavr-devel
[Top][All Lists]
Advanced

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

[Simulavr-devel] Re: simulavr 8515 now nearly complete


From: Theodore A. Roth
Subject: [Simulavr-devel] Re: simulavr 8515 now nearly complete
Date: Thu, 24 Apr 2003 09:50:18 -0700 (PDT)


On Thu, 24 Apr 2003, Klaus Rudolph wrote:

:) Hi Theodore,
:)
:) The SPI/WADO/UART is now in. The interrupts are cleared a bit and some
:) minor changes are finished. Only ana_comp is still missing but that should
:) be no problem, but how we should handle analog values to portpins?
:) That is the old questions how we interconnect to outside tools here.
:) Have you allready looked for any solutions?

I am always thinking about it, but have yet to find a good solution.

:)
:) I heared nothing from my last mail which can mean two things:
:) 1) You are angry about my redesign. :-). If so, please tell me!
:) 2) You are busy.

I'm not angry about a redesign as I know there are some problems with
my design choices. I am worried that a few things:

  - I haven't seen any patches yet. I can't give you any kind of
    feedback about your work without seeing it.

  - You didn't start with the latest cvs.

  - You seem to working up a big huge patch to send me. Huge patches
    spanning many features are incredibly difficult to review and I am
    not likely to apply a patch and commit it without understanding
    the repercussions. Whereas a small patch which adds one feature or
    rewrites a subsystem is easier to deal with. Another reason for
    small patches is to make tracking down when a bug was introduced
    easier, so it can easily be reverted if needed. A big patch with
    many differing changes to a file can not be reverted using cvs,
    but must be done by hand which is time consuming and error prone.

  - you should be discussing what you are doing on the simulavr-devel
    mailing list so any one else working on simulavr can see what you
    are doing. (sending mail directly to me only is a sure way for it
    to get lost as I get hundreds of email daily and work on many
    different computers).

  - I'm not really excited about C++. But, since I haven't seen your
    work, I have not closed that door yet.

And yes, I have been very busy and will be into next week when things
will slow down a bit.

:)
:) How we should continue now?

I think you need to bring you work up to date with the current cvs.
I've made a lot of changes since the last release.

:)
:) There is still a lot of work todo but the current system is
:) testable. There are some "printf- debug outputs" :-) in, but that
:) should not disturb you for have a look to the current state. It is
:) not a 1.0 version, it is still 0.1.x.

That's fine.

:)
:)  You spoke from a big patch for the cvs-version. There are any
:) changes for the core assembler functions inside? I think there are

You can see the patch in the simulavr-devel mailing list archives.

:) some open points in ELPM and other "newer" instructions. (I found a
:) lot of questions in the source comments :-). Currently all
:) instructions are available from all cores. That is not correct and
:) must also be fixed later. (no elpm in 8515 :-)

This was a conscious decision on my part. I'm relying on the compiler
to generate the correct code for a specific device. This make the sim
code simpler since you don't have to check the device type before
executing an instruction. Why must this be fixed? If the compiler
won't generate the instructions if the device doesn't use them, why
must the simulator waste cpu time checking them? If you can give me a
strong reason for changing this, I think that we could just insert a
NOP handler into the opcode lookup table for the missing insn.

Please don't stop your work. Simulavr needs to evolve and in order to
do that it needs ideas to come from more that one place (that being
me ;-)

Ted Roth




reply via email to

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