Literal translation into C

The following code was generated by applying the Einstein JIT compiler. Instead of creating byte code, TJIT was modified to write the C code that would have been called via byte code (ioUnits).

Even though it looks quite uncommon, the code below is legal C code and compiles just fine.

We can also see the main issue with transcoding an operating system (vs. a user mode application): NewtonOS relies heavily on the Memory Management Unit (MMU) for memory access. The LDR and STR commands must therefore be replaced by function calls (ManagedMemoryRead, etc.) which have a negative impact on performance. On the good side, once we transcoded everything, we can remove MMU dependency alltogether. But that is another story.

Compiler optimization

After running the C code above through our "C" compiler (Xcode 5.1.1 for Intel), we receive this optimized code. So 7 commands of ARM code have become 44 commands of Intel code. What looks like a bad ratio is not so bad at all, considering that this was a pretty primitive automated translation without human interaction.

Considering that half of the 8MB ROM is ARM code, out Intel ROM would grow to 27MB. By todays standards, an entire graphical OS including apps in 27MB would be incredibly small.

Compiler result

The compiled code is fascinating: after hand-optimizing a few lines of code into something that looks much cleaner to the human eye, the resulting code is still 31 commands long! This tells me two things: the automated conversion is not too bad at all, thanks to highly optimizing modern compilers, and, as a result of that, hand-optimizing is a complete waste of time.

The code we optimized away was the superfluous calculation of various flags in the comparison commands. I have not looked at the TJIT implementation yet. Maybe it can be further improved. The code is not optimized away by the compiler, because the flags are stored in a global location, and may be used later (well, we know that they won't, but the compiler can't know that).

One more thing!

There is a way that makes our transcoded app as slick and slim as the original. Here is some C++ code that may look similar to what the original NewtonOS source code may have looked like. What will happen if we translate that?

So it does work in the end

Compiling the hand-written code generates only 12 lines of assembler, proving that Intel code is not much longer than ARM code, and also proving that rewriting NewtonOS in C++ will lead to the best code.

But more importantly, this test proves, that automated transcoding can lead to something quite usable. In this particular case however, the MMU handling must be eliminated by hand-coding all memory allocation and task management functions.