Some aspects of the Java language are very attractive to embedded designers, especially when compared with the other object-oriented alternative: C++. According to Carl Dichter, senior technical marketing manager at Intel Corp.’s Appliances and Computing Division (Chandler, Ariz.), under Java it is no longer necessary to think about the size of variables, the byte-order in which data is stored by the processor, and which functions are available and how they operate differently on different platforms. Nor is it necessary to concern oneself with the different ways to allocate memory or figure out where to free that memory based on different exit points. And there are no longer different ways to process user events, to write things on the screen, to read from the keyboard or to load additional libraries. Most important, as a stack-oriented, interpretive language it is platform-independent, allowing programmers to write their code just once and be assured that it will run on virtually any platform.
Its downside as a language is that its greatest strength is also its greatest weakness: It is interpretive rather than compiled, said Paul Rosenfeld, director of marketing at Microtec (San Jose, Calif.), with all of the liabilities that implies: code bloat and execution times that are at best in the milliseconds. “Even with such things as just-in-time, flash and just-ahead-of-time compilers, you still pay a price. What you gain in performance you pay for in code size and memory requirements, and vice versa.”
Where Java as a language may find a place in the embedded market is purely as a programming environment. “It is an excellent environment to program in, especially for less experienced or beginning programmers,” said Tom Barton, director of marketing at Cygnus Solutions (Sunnyvale, Calif.). “It simply will not let you do the wrong things.” What is missing, he says, is the tool infrastructure: native compilers, cross compilers, linkers and debuggers.” Right now, most of the tools are desktop- and workstation-oriented, supporting only a handful of processors with the X86, Pentium and the Sparc accounting for the majority. Barton said: “What is needed is support for a wider number of processors and more tools oriented to the needs of the embedded market.”
For both traditional embedded applications and newer ones such as network computers and Internet appliances, there are alternatives. “The problem with these alternatives is that they have to buck Java’s almost overwhelming momentum in the marketplace,” said Ken Kaplan, president and chief executive officer of Microware Systems Corp. (Des Moines, Iowa).
For designers working in the deeply embedded applications environment who want to move to object-oriented languages but fear the code size and complexity, there is, says Carbonne, Embedded C++ (EC++). “What the developers of EC++ have tried to do is strip C++ down to the bare essentials that an embedded developer will need,” he said. “The result is a language that is very easy to learn and occupies not much more memory space than an equivalent amount of C code.”
The Limbo alternative
For embedded designers developing netcentric computers, Internet appliances and embedded Web servers, there is an alternative, from Lucent Technologies, the former Bell Laboratories-the original developers of both C and C++. It is called Limbo, designed for writing programs for use with Lucent’s alternative to the Java OS.
Limbo borrows from, among other things, C (expression syntax and control flow), Pascal (declarations), Alef (abstract data types and channels), CSP and Newsqueak (processes). Limbo is strongly typed, provides automatic garbage collection, supports only very restricted pointers and compiles into machine-independent byte code for execution on a virtual machine. A programming language, even with its libraries, is not enough, nor is it always the right place to solve all the problems of the network, said Ravi Sharma, technical manager at Lucent Technology’s Inferno Network Software Solutions Group (Murray Hill, N.J.). Therefore, Limbo is supported by the full Inferno environment that includes security and authentication, naming protocols, directory services, network interfaces and so on. When a Limbo program begins execution, it has a fixed interface to these services and is therefore inherently more portable than any language-only solution. One example is the network API, which is identical in all Inferno systems, independent of the hosting operating system or the network itself.
To achieve the goal of platform-independence, the JavaOS and virtual machine was created with as many of the platform dependencies removed as is possible, migrating them to platform-independent code. This minimalist kernel and the virtual machine are then used to implement all of the other services such as GUI support, networking, I/O drivers and the file system. Designed specifically to support the JavaOS, the kernel provides three basic types of services: booting, traps and interrupts, and thread support.
Without optimizing or porting to specific architectures to improve performance, the JavaOS, at the time of this writing, performs more than adequately for most network computing and Internet-appliance applications. Its TCP/IP throughput is about 500 kbits/second, more than adequate for most Web browsing. It is the memory requirements that should give Internet-appliance designers some pause and totally rule it out for more traditional embedded designs. At a minimum, without graphics code, no network support, no font support and no browser, the JavaOS can fit into about 128 kbytes of RAM and 512 kbytes of read-only memory. While that is more than adequate for many Internet appliances such as Internet telephones, portable Internet communicators, it is deaf, dumb and blind. Adding those features to make it workable could increase the memory requirements significantly. Also, the designer must factor in the additional RAM needed for applications and run-time requirements. At the high end, a complete JavaOS environment, consisting of the OS and the HotJava browser, can fit into about 4 Mbytes of ROM and 4 Mbytes of DRAM. Not factored into this is the memory space required for downloaded HTML-based Web pages, which amounts to at least 1.5 Mbytes, if you are ready to compromise on performance to some degree.
As far as Windows CE is concerned, it has largely been written from scratch to fill the niche for a small scalable 32-bit Windows-compatible OS, and still borrows heavily from its bigger brothers, supporting the familiar Win32 programming model and incorporating a subset of the Win32 API. In terms of programming space, the CE kernel is less than 150 kbytes and the Windows shell will boot with under 500 kbytes of DRAM. While this is substantially larger than designers of deeply embedded microcontroller-based applications are comfortable with, said Annasoft’s president Dick Eppel (San Diego), it is more than adequate for many high-end applications. Moreover, he said, like its RTOS competitors, Windows CE has been designed modularly, so the memory footprint can be reduced considerably, by removing unneeded functions.
The tougher issues facing both Windows CE and the Java OS are their real-time response characteristics. According to Eppel, the Windows CE kernel has a low interrupt-service routine and low thread latency, allowing threads to be scheduled and switched in less than 100 microseconds with a CPU operating at 33 MHz. And JavaOS, say many developers, looks like it can operate in the same ballpark.
Work is under way in both environments to improve real-time performance. On the Windows side, many of the same vendors who have come up with real-time versions of NT and 95, including Annasoft, Venturcom and Radisys, are applying the same techniques to Windows CE. As far as Java OS is concerned, JavaSoft at Sun Microsystem’s JavaOne conference earlier this year introduced eJava, an embedded Java API that is aimed at reducing the memory footprint and improving response characteristics.
Search for determinism
Beyond response time and memory footprint, the two OS alternatives, said Simon Waddington, senior engineer at Wind River Systems Inc. (Alameda, Calif.), are both seriously lacking in their ability to provide deterministic performance. “Determinism, more than response time or clock rate is the one defining characteristic of real-time systems: guaranteed responses to events at specific times within guaranteed limits,” he said. Of the two environments, said Dan Hildebrand, senior architect at QNX Systems Software Ltd. (Kanata, Canada), Windows CE can probably be made more real-time the easiest. “The real problem will be how to make the Java virtual machine and the Java OS more deterministic,” he said. “The way Sun has implemented garbage collection in the Java model makes it almost impossible to guarantee response times.”
Additionally, both OS alternatives do not have the best disk storage management systems. Often, their usage in RAID storage environments can aggravate hard disk failures at a rate much higher than other some more popular choices. As well, their mobility can sometimes be a risk, and require some form of professional laptop data recovery once usage becomes heavy.
Specifically, says Cygnus Solutions’ Barton, garbage collection is not under the control of the programmer and can occur at any time. “That can really play havoc with a real-time application,” he said. In Javasoft’s eJava, said Curtis Sasak, Java platform product line manager at Javasoft (Mountain View, Calif.), the effect of garbage collection on real-time response is not dealt with directly: “However, the fact that the memory footprint is much smaller means that garbage collection can be completed much more quickly,” he said, and at the very least, worst-case numbers for the time it will take to perform the operation can be guaranteed.
A number of RTOS vendors are looking to solve this problem. Wind River Systems Inc., for example, is replacing the Java OS kernel with its own real-time, multitasking, multithreading VxWorks kernel; in essence running the Java Virtual Machine atop its RTOS. Integrated Systems Inc. (Santa Clara, Calif.) is taking a more direct approach. Working together, ISI and Newmonics Inc. are developing a “clean room” version of the Java OS/VM in which garbage collection can either be eliminated, scheduled or at least speeded up and applied to smaller chunks of memory at a time.
For embedded designers heavily involved in net-centric applications such as Internet appliances and Web/TV combinations, there is also an alternative to the Java OS: Inferno, Lucent’s OS companion to Limbo. Where Java is an object-oriented language deriving its inspiration from C++ and Pascal, among others, and JavaOS is designed to handle objects, Inferno is file-based and draws upon the experience of the past and incorporates many features, such as garbage collection, and eliminates many of the sources of error in past languages, such as overdependence on pointers.
In a significant departure from the Java model, however, Lucent has taken a different approach to implementing a virtual machine. While programs written in Limbo are compiled into byte-codes representing instructions for a virtual machine called Dis, the VM is a memory-to-memory architecture, not a stack machine, that translates easily to native instruction sets. In fact, many Dis instructions translate to a single Pentium instruction. The on-the-fly compilers are small-the implementation for Intel 386 architectures is only about 1,300 lines of C-and result in code that performs within about a factor of two of compiled C. For the same reason, the Dis interpreter is considerably smaller than the implementation of the Java virtual machine.
“The Limbo/Inferno combination looks as if it has everything that Java has and more, as far as networkability is concerned,” said Hildebrand. “Unfortunately, Java has market momentum with it and practically no one knows about Limbo.”
However the embedded market sorts itself out with regard to these new language and OS issues, said Vik Sohal, senior technologist at Lynx Real Time Systems Inc. (San Jose, Calif.), there will be at least two benefits. First, it has reminded programmers that there is still room for interpretive languages. “At the very least, the Java model with its platform-independence has given us something we have tried hard over the years: a common applications binary interface,” he said. “With a few extensions Java will be an ideal way, once the compiler/cross-compiler tool infrastructure has been built, to port code between different processor architectures.”
The other significant benefit is that the embedded market is being forced to move much more aggressively toward object-oriented programming and methodologies than in the past. “The momentum, before Java, was building, but slowly,” said Vladimir Ivanovic, technical marketing engineer at Microtec. “But now the pressure is on in all directions.” The ubiquity of embedded processors, in everything from toasters to network routers and Internet appliances, said Waddington, means that such applications are now a part of the social infrastructure, dictating that reliability and fail-safe operation is important not just in some mission and life-critical applications, but also in all applications. “This means that at the very least a shift to object-oriented programming methodologies even when coding in C,” he said, “and, at most, a shift totally to an object-oriented language environment.”