The next platform for your embedded application will use a new processor, and the original software must run on it next week. Depending on the original system architecture and the tools available, the task can be either a breeze or a nightmare.
This scenario illustrates the problem today's designers face when attempting to jump to new platforms while keeping the same software. Many choices exist, but each has its own pros and cons. Let's take a look at those options.
The table outlines the three general approaches to porting code: recompilation, virtual machines, and machine-code translation. Each has different benefits, requirements, and drawbacks. For example, recompilation is only possible with source code present.
Source code availability is preferable even when employing technologies like virtual machines and machine-code translation because of debugging considerations. The big problem with any porting exercise is always compatibility, and 100% compatibility is hard to come by, especially when the new target adds features or peripherals.
Another consideration is the support code necessary by an application (see "Making Apps Run," p. 78). Small microcontroller applications can often run without additional support code, but anything larger includes at least an operating system. Building an operating system from scratch for an embedded application is still a viable alternative, although using a third-party operating system is pretty standard.
Unfortunately, the source code for support programs can be expensive, which is one reason why Linux, with its General Public License (GPL), is a popular embedded solution. Many real-time operating-system (RTOS) vendors include source code as part of their base package. A number of them still keep their source code closed, yet Microsoft permits peeking under the covers.
Portable Source Code: In addition, the destination must have a compatible compiler. C and C++ are the two most popular compilers, but this can be refined further as C++ provides undesirable or unnecessary features for embedded environments.
Embedded C++ (EC++) is one common subset that works with compilers from a number of companies, such as Altium Tasking. It eliminates advanced features like multiple inheritance and templates. The idea behind it is to make EC++-based applications less complicated in terms of language features. As a subset of C++, EC++ lists the things that won't be implemented.
Subsetting the C runtime also is useful for embedded environments and portability. The POSIX standards define a range of interfaces for everything from file access to multitasking support. Migration at the source level is significantly simpler if the application can adhere to this more limited support interface. POSIX works with most operating systems.
Another operating environment is OSEK/VDX. Primarily employed for distributed control in vehicles, the OSEK standard is helpful in other embedded environments as well. Green Hills Software's Multi 2000 Integrated Development Environment runs on OSEK-compliant operating systems.
Unfortunately, even with proper programming practices, a lot more details can crop up when switching from one platform to another. Some issues are memory mapped versus port-mapped I/O, big- and little-endian numeric encoding, and even floating-point formats. The object of migration is getting a system to function with an existing infrastructure, which could entail exchanging data across devices or platforms. Switching from an x86 environment to a PowerPC can grow tedious even with source code.
Virtual Machines: Hiding the underlying platform from the application and interposing a virtual one between the application and hardware eases migration. Many years ago, the Pascal P-System took this approach, allowing Pascal applications to be compiled once and run on a wide range of hardware without modification.
Among others, Sun's Java is the most notable implementation that uses a virtual-machine (VM) architecture. Both Microsoft's .NET CLR (Common Language Runtime) and Vita Nuova's Inferno use VMs. Every one defines a bytecode instruction set similar to the Pascal P-System. With this approach, the VM's machine code is tailored to the language that it was designed for.
Although a VM can be optimized for a particular language, it's not prevented from running applications that generate the appropriate bytecodes. The Pascal P-System functioned with numerous compilers in the same fashion that Microsoft's .NET supports a range of languages from C# to Visual Basic .NET to Eiffel .NET. Even Sun's Java VM, or JVM, contains compilers for other languages like Forth and Scheme (a version of Lisp).
The advantage of a VM specification is that a programmer only needs to deploy the instruction set so that the application will run accordingly. Initial VM implementations are typically bytecode interpreters, but this is just the tip of the iceberg.
Companies like NewMonics, IBM, and HP offer Java VMs that compile Java bytecode applications to native code. Just-in-time (JIT) compilers do this on-the-fly as a program is executed, while ahead-of-time (AOT) compilers generate native machine code before the program runs. Advanced VM implementations can mix JIT, AOT, and interpreted operation, because there's usually a space/performance tradeoff when using native code.
While native code generated from a C++ compiler is typically faster than native code generated by a JIT or AOT JVM compiler, the difference is due to the kind of checking performed by a JVM. This is part of the language specification. Checks verify that array indices are within range.
Another source of overhead is garbage collection. Although not a VM requirement, most modern VMs work with languages that have garbage collection. This minimizes programming errors such as dangling pointers and memory leaks, typical with C and C++, among others.
Reprints
