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.
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.