Elate's® Translation Process

The Elate® Operating System makes use of the concept of a Virtual Processor to provide binary portability of both applications and the operating system itself across a broad range of processors. Code is written for the virtual processor - an imaginary little endian 32 bit RISC machine - and is then translated into the code of the required platform or processor at either load or run-time. Efficient translation can be achieved on RISC, CISC, VLIW or other processor architectures irrespective of the target processor's endianness.

It ought to be stressed that where other operating systems may have "portable applications", Elate can be ported in its entirety, including libraries, kernel and device drivers. Elate is a truly portable system. The only substantial piece of code to be rewritten is the translator. A translator can be created for any type of processor - Microprocessor, Microcontroller, and so on. Furthermore implementation of a translator for a new processor architecture requires no more than a few man months of effort for an optimised version. A kernel port can be done in a matter of weeks. As soon as the translator is operational all Elate functions and applications will be able to run. Put simply Elate eliminates the need for any time consuming and expensive rewriting, and makes porting to a new platform totally straightforward.

The technique takes application code and converts individual or sequences of VP instructions into individual or sequences of native instructions for the target processor. The VP instructions are loaded from ROM or disk storage, they are translated and the resulting native code is stored to processor RAM for execution. The translation phase occurs during load time, but can be static as defined by the developer. It allows very focused optimisation to be performed for each individual target processor. It should be once more stressed that translation is a wholly different approach from interpreted techniques in that translation occurs at load time, not at run time.

An interpreted system also suffers an ongoing run time penalty, often running 10 to 100 times slower than direct execution. However many times the same piece of code is encountered, it must be decoded each time prior to execution. In the case of a translated system, however, all decoding takes place during load time. Once translated, all code is stored, and henceforth executed, as native code.

Applications are held in storage as a number of tools. As each tool is loaded the Virtual Processor codes are analysed and the appropriate sequence of native processor machine code instructions are generated and stored in memory.

The application is held in memory as separate tools, each called by the main thread of execution. Native code is being executed when a tool is called so there is no runtime penalty introduced by the translation from VP code. Translation only occurs when a tool object is loaded into memory.

When the referenced tool is already present in memory, it is executed immediately, so the small translation overhead is incurred only on the first call to the function. This first call could have been made by a different thread of execution. Elate is multithreading and each tool object can be referenced by any number of threads of execution.

During the load phase there is a small time required by the translation process. This time is however measured in tens of machine cycles to translate a single VP instruction. When an image is being brought in from disk or a network the speed of these media is such that the total load time is dominated by media access time. In fact, faster load times are possible as a result of VP code density. The VP machine code specification was designed for translation. Without the need to implement a bit pattern which allows efficient silicon design, a bit efficient instruction set was designed to maximise code density in storage. Thus an application in VP code in general requires less storage space than the native codes into which it will be translated. The compression ratio offered by VP code is dependent upon the target processor architecture, but ratios from 1.4:1 up to 2:1 have been measured.

When executed, both VP programs and native programs need to be loaded from storage to the processor. The native code goes directly to memory, the VP code being translated before loading into memory. The translation of a VP2 code to native takes a few tens of machine cycles, significantly less than the time to load that code from storage. There are fewer bytes to load for a VP code application than the native code version so the load time will be less. The translation phase also overlaps with the loading of the next instruction to be translated, exploiting time which would otherwise have been lost. A significant reduction in time to load and execute a VP code program over a native code program can therefore be gained.

The benefits of smaller binary images has application in desktop environments to speed transfer from disk, in embedded systems to use less ROM, and in networked devices to speed application delivery. The translation phase also allows single application images to be supported across different user platforms whilst still being optimised for each one.

Each translator is specific to one processor variant. This ensures the optimum performance from the generated native code. The Tao Translator team builds into each translator a detailed knowledge of the target processor architecture and instruction set. For instance, for embedded environments manufacturers can select Elate to translate statically instead of at run time. Application and kernel functions can then be stored in native machine code.

It is not necessary for programmers to learn VPcode in order to make use of Elate. Code written in other languages may be compiled or assembled into VP before being stored. A range of languages may be compiled into VP assembler code. This may then be converted into VP binary by the VP assembler. Compilers for C and C++ are already available.

The high level language tools available also fully exploit the powerful features of Elate, allowing maximum re-use of software, programming resources and significantly reduces support and maintenance effort.

To access specific hardware features of a processor, translation and dynamic binding form a powerful combination to ensure an application gives optimum performance on whichever platform it runs.