[NTLK] Einstein Simulator Status Update 2

[Matthias Melcher]

OK, well, it took a while, but I am very happy to tell you that I managed to move one of the more important functions from emulation to simulation: the main ByteCode interpreter loop (TInterpreter::Run1).

It's a quite complex function, and covers a tiny fraction of the code, but the results in NewtTest 1.1 are impressive: the speed test loop (which admittedly uses the interpreter a LOT) improves speed by 30%. 

This is from implementing just one function. Imagine what we can do with more and more functions re-implemented in native code.

From today on, I will try to write one new function a day... .


Geek part:

OK, so the code is not ready for prime time yet. If there is interest, I can send a private copy. I will also continue to get structure into what I wrote and publish the result to the SVN archive on Google code.

The simulator has five functional parts:

One part is a collection of native functions as they are implemented. There need not be a particular order because we can jump back and forth between simulation and emulation, but it makes sense for performance resons to start with an existing code segment and work either down the call tree to the functions called directly, or up the tree to the callers.

Part two contains interfaces from simulator to emulator. Whenever a natively implemented function calls a function that is not native yet, it falls back into emulation mode. To do that, every function called needs a little (three liner) stub that provides a correct C/C++ declaration, but executes the ROM code via emulation. BTW: if you feel like giving this a try, implement one of these functions!

Part three contains the opposite of part two. Here we have a stub (a short function) that patches the ROM and makes the emulator call a native (simulated) function. These stubs (as the ones in part two) are smart: only if the C/C++ module is linked in, the patches will be applied. This makes it easy to disable one or all patches by simply not linking that source file.

Part four is a called the Glue. The Glue is a collection of macros and classes that will make the life of the simulator author a lot easier. The simulator has two run modes: in mixed mode, the simulator uses the emulator RAM so that we can jump back and forth between simulator and emulator. In native mode however, all the smartypants macros replace the emulator RAM access with simple original and full-speed C/C++ code. By using the macros, all simulator code will run in mixed mode *and* in native mode.

Part five deals with native mode alone. It is not yet implemented, but as soon as we have a sufficient number of native calls, I will add test modules that will run meaningful code without the need of the ROM, the Emulator, or, heck, anything of Einstein. The code will run full speed and on our own license, but it can only ever be a subset of NewtonOS.

Any help is as usual greatly appreciated.

 - Matthias