Einstein Would Be Magnificent

[Exophase]

Um, I am afraid I got my numbers wrong. Emulation speed *was* 200:1. JIT raise the bar to 40:1 IIRC. It is usable on my Macbook Pro.

That's certainly an improvement. When you list those ratios are you talking about clock speed of the original Newton (20MHz, ARM610) vs clock speed of what you're running on now (so say, 2GHz x86 of some sort, although that leaves a lot of room.. I'm going to shoot down the middle and go with Core 2 Duo since you now say Macbook Pro). So the 2GHz laptop is running it at 2.5x real time speed w/o throttling, hence would run it at 1x realtime speed at 800MHz, this 40 times the clock speed of the original Newton?

I ask all of this because it has a big impact on what the performance could be like on devices that aren't x86. Cortex-A8, for instance, will be significantly weaker per-clock than a Core 2 Duo, I would expect something on the order of 1/2 performance typically, although that's a very rough guess. It also has a large bearing on whether the numbers are "good" or not.

Exophase, I'm very interesting about your thinking that Einstein could be heavily improved in efficiency. Matthiasm could help about how Einstein works and then try to ellaborate some way to making it fast.

I reasoned that based solely on the numbers provided and what was mentioned. This is regarding x86 performance, which could be moot because Einstein's changelog claims that it has experimental direct ARM to ARM translation. From what little I could tell not that much was actually implemented to this end. I'm still trying to good a good handle on what the code actually does. The code base is really heavily split over lots and lots of files and some things are hidden behind a few layers, which makes it take a while to really get a broad understanding of it. I'll post again once I've figured out how it works more concretely >_>

But chances are good that it'll be easier to graft in another ARM->ARM recompiler than get what's there working as well as it needs to (am basing this off of current reported performance on other mobile devices). At the very least the JIT in Einstein seems pretty complex, although this could just be me.

 

[matthiasm]

The Newton 2100 (which is the only one worth emulating) runs at 162 MHz. Emulating on my 2GHz Macbook Pro runs about half speed (but that's quite hard to say). The emulated commands are generated using #defines that use #defines, an amazing grid that generates every possible ARM command. The ARM to ARM emulation is limited to the "div" command. It hit the wall when the MSB/LSB problem and MMU emulation started to throw a wrench into the system. Ignore all the Albert stuff. It was my attempt at partially translating into native code.

 

[Exophase]

The Newton 2100 (which is the only one worth emulating) runs at 162 MHz. Emulating on my 2GHz Macbook Pro runs about half speed (but that's quite hard to say). The emulated commands are generated using #defines that use #defines, an amazing grid that generates every possible ARM command. The ARM to ARM emulation is limited to the "div" command. It hit the wall when the MSB/LSB problem and MMU emulation started to throw a wrench into the system. Ignore all the Albert stuff. It was my attempt at partially translating into native code.

Sorry, but you've lost me with the ARM to ARM emulation part, given that neither StrongARM nor any ARM for that matter that isn't v7m has a divide instruction. I saw multiply and multiply-accumulate were marked as "isNative", but this doesn't make that much sense to me either without more information.

162MHz StrongARM is quite a tougher target to hit, and with a requirement of full software MMU emulation I think you won't be able to quite attain it.. but I'd be really surprised if standard Newton software was really using all of that CPU time. It's also probably pretty heavily saddled by the memory subsystem since it only has 4KB of unified cache.

It looks like what the JIT is doing is generating a list of function pointers, then has a loop executing them. Each function returns a pointer to the next function, which handles flow control. Inbetween, interrupts are checked for. The huge array you refer to is an expansion which has specialized versions of the functions for at least one register and other opcode bits. It's done to avoid having to have additional functions to prepare the arguments, but it's probably eating through instruction cache since there are simply thousands upon thousands of functions generated with a relatively low degree of repeatability between instructions.

Like I described before, this is a threaded interpreter and does well in removing overhead of fetch and and some of the overhead of decode, which is especially useful in ARM emulation. But it only really scratches the surface when it comes to what you can do with a recompiler. The overhead of calling through a function pointer for every instruction is going to be pretty high, especially without being chained at the end of instructions - you're probably going to see a branch mispredict every instruction on modern archs. Checking for interrupts every instruction will have a lot of overhead as well, and a lot of time is likely spent on things like flags. I'm actually a little surprised that this is all as much fast as you claim, because I think even a pretty poor interpreter shouldn't gain a 5x increase in performance with this implementation.

 

[timofonic]

The ARM to ARM could be quite interesting if being enough flexible. Think of RiscPC, GBA emulators for example being more power efficient too.

 

[Exophase]

The ARM to ARM could be quite interesting if being enough flexible. Think of RiscPC, GBA emulators for example being more power efficient too.

gpSP (GBA emulator) is already employing ARM to ARM dynamic recompilation. If someone wants to adapt the code they're free to use the source; it's far from the best recompiler in the world and it's only ARM7TDMI (StrongARM doesn't add anything instruction wise, and you could remove the Thumb stuff) but it should provide better results than what Einstein currently has. However, something would still have to be done to address the endian and MMU emulation.

I know of some other open source ARM recompilers but none that translate to ARM, maybe someone knows of one?

 

[matthiasm]

Exophase: yes, you are right, it was the multiplication function. The last time I checked that part of the code was tree years ago.

Sure, the JIT could be greatly improved. Paul did a fantastic job emulating the undocumented hardware and drivers of the Newton. The JIT is AFAIK a collection of other JIT implementations. The proof of concept worked. He then had to leave the project for undisclosed reasons. I started replacing individual functions with native code. The goal was to replace the interrupt functions with native code which would have remove the overhead of emulating interrupts (which are polled at every jump instruction, not every instruction).

OTOH, 99% of all Newton software is written in Newton Script which is an interpreted byte code. There is no reason to emulate any ARM instructions beyond thr code in ROM and maybe a handful of drivers. IMHO, it would be best to translate the ROM into C and C++ (which it was written in anyway, and remember, we have the complete symbol table!), and then simply recompile it for any platform that is out there. By skipping the emulation, we would run at 100% speed of the *host*! That way, we would solve battery consumption, interrupts, and MMU usage.

One word on the MMU: the Newton uses the MMU for only one purpose (described in a publicly available patent). When launching a program, only one block at a time is (possibly decompressed and) copied from mass storage (Flash RAM) to memory. Whenever the interpreter would access a part of the program that was not yet in RAM, the MMU would trigger a memory fault and NOS would copy yet another block from the mass storage to RAM, mapping it to the linear address, possibly unmapping other applications.

Back in the days, with 1 MB RAM and 4 MB "Mass" Storage, this was the only way to run meaningful apps. Today with 80 MB of RAM and 32 GB of mass storage (depending on the target device), this remaping should simply be removed. NOS would no longer need an MMU, removing the biggest bottle neck of them all. But again, that would require changes in the ROM, which brings me back to recompilation.

The Newton is a truly unique beast, and a wonderful and worthy target for this kind of work.

Matthias

 

[Exophase]

So we're back to talking about something totally different from an emulator, a NewtonScript VM. Did the Newton itself fully interpret this? If a recompiler is made for Newton Script then the result would be much faster than even a Newton of the same CPU capabilities could perform..

 

[timofonic]

I don't want to interrupt this nice discussion, but this could be useful?

http://trac.so-kukan.com/newt
http://gnuton.sourceforge.net/

Maybe developing a NewtonScriptVM could be too much, but it seems there has been some attempts to write one with some success degrees.

 

[matthiasm]

http://trac.so-kukan.com/newt
http://gnuton.sourceforge.net/

Newt/0 is great. It is a fully working Newton Script interpreter and compiler. Newton Script however is only a tiny part of Newton OS. Gnuton has been abandoned man years ago.

 

[timofonic]

http://trac.so-kukan.com/newt
http://gnuton.sourceforge.net/

Newt/0 is great. It is a fully working Newton Script interpreter and compiler. Newton Script however is only a tiny part of Newton OS. Gnuton has been abandoned man years ago.

So Newt/0 + the remaining bits by recompiling is the way to go then?

I did read about DyneE5, it was going to be an emulator but finally a Newton IDE.

http://code.google.com/p/dynee5/

 

[matthiasm]

So Newt/0 + the remaining bits by recompiling is the way to go then?

I did read about DyneE5, it was going to be an emulator but finally a Newton IDE.

http://code.google.com/p/dynee5/

I wrote DyneE5 when Einsten came out closed source and go pretty far (memory initialization, first dialog box on screen). When Paul opened the source to Einstein, I took my knowledge and combined my app with Newt/0, creating DyneTK, an IDE to develop Newton applications. I expanded Newt/0 to read and create Newton packages, etc. . This all mostly works.

Still, all that effort is miles from a true Newton. What make the machine so great is the ability to naturally write and draw anywhere, to have all apps cooperate, to be able to extend existing apps without having their source code, to have an integrated database of a file system, and much more. Newton Script is a pretty good language and has a very nice API. It's one piece in the puzzle, however the combination of all features makes the Newton so great.

Matthias

 

[sphinx32]

I'm wondering if some devs will be porting Einstein to OpenPandora handheld with current Einstein code, even it is much slow than original newton.

In addition, Pandora's Keyboard supporting to Einstein would be great, and maybe importing to Einstein ARM to ARM emulation part
to see if these are helpful of speed.

 

[timofonic]

I'm wondering if some devs will be porting Einstein to OpenPandora handheld with current Einstein code, even it is much slow than original newton.

In addition, Pandora's Keyboard supporting to Einstein would be great, and maybe importing to Einstein ARM to ARM emulation part
to see if these are helpful of speed.

Tes, some experimenting with the code could be quite interesting. Any volunteer developers for some code hacking?