Introduction
This is a list of steps that can be taken to improve emulation speed, targeting a mostly native implementation of NewtonOS for a wide range of hosts.
The Idea
January 28t, 2010: there we have it, the iPad. Nice shape, OK software, but not a Newton - of course.
Since we have a working Newton Emulator for OS X and the iPhone SDK is pretty much only a reorganized Cocoa interface, and since the iPad's now running at 1 GHz, it may actually be the time to move Einstein to the iPad.
It would still be a slow emulation, and that's where my call to all of you comes in: can we go from emulation to simulation to native code? Can we accelerate Einstein to run ten times faster, a hundred times? Can it be a made to run on all handheld devices out there?
Sure, we just need to focus! It's all there.
Bottle Necks
There are two bottle necks in the Newton emulation. Both can be widened or even removed, using native code and a fallback option for unexpected conditions. We can work on both bottle necks simultaneously.
Bottle Neck 1, MMU Emulation
The MMU needs over 50% of the emulation time. The goal is to simplify and finally remove all dependencies on the MMU from the Newton ROM.
(add a link that explains why and how the MMU is used by NewtonOS)
- 1.1: find the code in ROM that creates memory pages that are not mapped to RAM yet
- 1.2: intercept all callers and make them allocate true RAM instead of MMU pages
- 1.3: verify in Einstein that no more MMU hits are created at run time
- 1.4: remove 90% of MMU emulation from Einstein, doubling emulation speed
Bottle Neck 2, CPU Emulation
Einstein uses a JIT compiler to convert every ARM instruction into a table lookup which then emulates the given instruction. The goal is to replace often used code segments in NewtonOS with native "C" code.
(add a ink to a page that explains how we can mix native and JIT code, and how we can safely continue emulation, even when the MMU causes and exception)
- 2.1: use the symbol table and the ROM to create a complete C++ source tree
- 2.2: use analysis tools and hit counting to find the functions that are called most often
- 2.3: compile those into Einstein and patch the ROM (we already do that)
Further Migration
The goal is to create as much native code as possible by auto-generating C++ code from ROM.
- 3.1: use the knowledge from task 2 to improve the interpreter from 2.1
- 3.2: fill in the missing information that is not in the symbol table
- 3.2.1: find return values where they are needed
- 3.2.2: replace all access to fixed addresses in RAM with symbols
- 3.3: remove the remaining MMU emulation
- 3.4: compile natively and relocatable code and make NewtonOS into a user-space application
Compatibility and Dirvers
The goal is to create drivers for many platforms and operating systems.
- 4.1: with NewtonOS running natively at full speed, create a standardized driver interface
- 4.2: write screen, touch, sound, etc. drivers for all target platforms
- 4.3: enjoy!
As a result, NewtonOS will run on any platform with over 200 MB of RAM, a pointing device, and a graphics screen. In terms of 2010: on pretty much anything - including the iPad.
If enough capable people would get involved, I'd be happy to set up the development environment and dedicate a fixed amount of time per week. Much of the work has been done already, but has not been focused enough. This would be a great chance.
