[NTLK] Einstein Simulator Status Update

Steven Frank stevenfrank880 at gmail.com
Wed Sep 19 13:33:33 EDT 2012


I looked at how you implemented CArrayIterator last night, and did my
best to try to understand it.  I think the main thing holding me back
from adding new simulator methods is not knowing where to find the
appropriate documentation on the Newton side.  For example, to
implement a method in the simulator, you need to know at least:

- The ROM address of the method you're patching (I have a symbol dump,
but I'm sure most people don't)
- The method signature, including types
- Return type
- Offsets for the class's instance variables (I assume the purpose of
the SIM_GET_SET_W() macros is to map these to RAM in the emulator (?),
although I don't fully understand it yet.)
- What the method is actually supposed to do.  :)

I hit a dead-end on a lot of these steps and wasn't able to add
anything useful to the simulator successfully.

A quick how-to on where you're gathering all this information from
might be helpful, at least to me, if not others who would like to
help!  Especially with URLs to resources if they're available online.
(I can even host files at einsteindev.com)

But since I had the project open, I fixed a few Xcode warnings.  :)
In my earlier message I said this might drop compatibility with OS X
10.6, but it looks like it was already targeting 10.7 before I
started.

The other thing I noticed is the OS X app only builds for 32-bit.  It
might be tricky to make it 64-bit clean, but this is something I could
look into also.

Steven


On Wed, Sep 19, 2012 at 12:16 AM, Matthias Melcher <mm at matthiasm.com> wrote:
>
> On 19.09.2012, at 02:55, Steven Frank <stevenfrank880 at gmail.com> wrote:
>
>> Matthias,
>>
>> That's some pretty amazing stuff.  Do you have any clues about which
>> C++ classes are most commonly hit, other than CArrayIterator?
>
> No. I did implement a hit counter for every jump instruction, and that gives me some clues, but I have never analyzed actual performance. CArrayIterator was randomly chosen because it does not call any other classes and I already had the code.
>
>> It looks like the native CArrayIterator you provided doesn't implement
>> every method from the ROM.  Do these automatically fall back to
>> emulated ROM code?  Insane.  :)
>
> Yes, they fall back to emulation. Event hough this is native code, all memory access is also done in emulated RAM. By changing the Macros in Sim.h, all code can become truly native, stand-alone, and full speed.
>
> I have been thinking about where to start. Originally, I wanted to rewrite the virtual memory handling, assuming it is called a lot. I changed my mind because it is actually not called that often, and if we go completely native one day, this is the first code to be thrown out anyway.
>
> Currently, I am pondering if we should start with the Byte Code Interpreter loop and work our way down from there. It would be relatively easy because we have two Byte Code interpreters as C++ source available already (one of them is NEWT/0). It would also be very rewarding because there will be a time when this interpreter will works stand-alone, even if not all subroutines are there yet.
>
> So here is my List:
>
> - implement the Byte Code interpreter loop: TInterpreter::Run(...) and Run1(...)
> - implement all functions that are called by TInterpreter::Run(...) (but no the individual native code that can be called - that would be much too much for a first step)
>
> At this point, we should have a quite fast byte code interpreter.
>
> - implement a native app that makes it possible to call TInterpreter::Run(...) without Einstein, and verify that our code is correct.
>
> Now, we can run Byte Code without launching Einstein. No exciting programs yet, but the basic structures would be there.
>
> - implement the package loader
>
> Now we can run (simple) packages without Einstein around, or we can run complex packages within Einstein at a much greater speed.
>
> - implement the native calls as needed and based one performance analysis
>
> Einstein gets faster and faster, the stand-alone interpreter becomes useful.
>
> - implement the rest ;-)
>
> ====================================================================
> The NewtonTalk Mailing List - http://newtontalk.net/
> The Official Newton FAQ     - http://splorp.com/newton/faq/
> The Newton Glossary         - http://splorp.com/newton/glossary/
> WikiWikiNewt                - http://tools.unna.org/wikiwikinewt/
> ====================================================================



More information about the NewtonTalk mailing list