next up previous
Next: What uCR is Up: Embedded Programming with C++ Previous: The Problem

uCR, C and C++

The difficulty of porting embedded operating systems is more often dealing with the board, and not the CPU proper. It is the memory layout and I/O devices that make portable operating systems difficult. If one can reduce the development environment to something independent of the board, then there is only the CPU to worry about and not all the devices around it. uCR/i960 can run on any i960 without porting.gif

Eliminate the devices from the environment, and eliminate the system call gate, and what remains is a runtime that connects the compiler to the CPU. In the embedded world, anything is possible and imposing irrelevent requirements like a console and a clock ticker can make things harder.

The problem, then, simply reduces to how one maps C++ to a CPU, with nothing else. Although board specific code still needs to be written, specifically the reset handler and application code, uCR makes no requirements other then those needed to support the compiler. This is a task to remind one about the nature of a programming language.

This is not quite the same as more conventional development environments requiring board support packages. Although uCR in practice needs board-specific startup code, it does not impose a style of interaction with the board and programmer. Typical systems require of the board support package console drivers, timer drivers (with the timer configured to tick at a specific rate) and package drivers to initialize the options you choose to include. uCR imposes no such requirements.

Stephen Williams
Sun May 4 15:28:26 PDT 1997