[NTLK] Einstein Simulator Status Update

[Matthias Melcher]

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 ;-)