Skip to content

Development Strategy

Jump to bottom
Matthias Melcher edited this page Feb 5, 2022 · 4 revisions

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.

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 Drivers

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.

Clone this wiki locally