Kelvin Nilsen
Embedded.com

An intriguing pair of articles posted recently on Embedded.com (B#: A programming language for small footprint embedded systems applications,Part 1 and Part 2, by Michel de Champlain and Brian G. Patrick) raised important questions regarding the future of embedded computing.

Accompanying these articles in the Embedded.com newsletter  was editorial commentary by Embedded.com Editor Bernard Cole. The commentary indicated that the response to the B# articles was the strongest of any online article in quite some time, suggesting that the subject matter struck a chord with many people.

The editorial comment that accompanied the B# articles stated that “The response (the readers) have had to the B# series on Embedded.com tells me that if the Java community does not quickly respond to the need, developers will move on to somebody who will.”

It is interesting in this context to note that a study by Embedded Market Forecasters [3] asked survey participants that had opted against using Java to specify the reasons for their decision. Key reasons identified included:

Run time speed is slow
• Memory requirements are large
• Inability to satisfy hard real-time constraints
• Inability to perform low-level operations
• Inadequate support for target systems
• Startup time is too long
• Inability to satisfy soft real-time constraints
• Lack of safety certification

The articles by de Champlain and Patrick introduced a new language and virtual machine called B#, intended to provide an object-oriented evolution of C giving some of the advantages of C++ while maintaining compactness, and providing a portable threading abstraction intended to run on top of an interpreted virtual machine, yet without the baggage typically associated with Java.

These are noteworthy ideas and the effort is a noble one, but the articles beg the question: Do we really need yet another programming language and VM architecture? Or do we have existing alternatives that can achieve the desired goals within an already recognized and commercially accepted framework?

The salient point of the B# articles was that the C language and paradigm is aging and fragile, but nothing sufficiently worthy has emerged to fully replace it in the realm of resource-constrained applications. This disparity is disconcerting given the rapid expansion of embedded devices, not only in volume of device deployment, but also in application complexity. Worthy successors to C have been suggested, but none have yet fully gained traction in the resource-constrained community for a variety of reasons. For example:

C++ - While in many ways an improvement over C, C++ nevertheless increases the complexity of the language without addressing many of the core flaws of C, such as type insecurity, unsafe memory operations, a lack of portable low level operations, and no portable threading model. Further, although many surveys will show C++ as the dominant language in embedded computing, evidence indicates that many who are using C++ compilers are primarily using the C subset of the language, typically avoiding object orientation and other C++ features entirely.

Ada – The Ada language, a chronological contemporary of C and C++, offers technological advantages comparable to Java and has been shown to be quite effective for resource-constrained and safety-critical applications. The roadblock for Ada is not technological. Ada has failed to gain widespread acceptance for historical reasons stemming from its inception and incubation as a government sponsored, military-mandated language in the mid-80s to mid-90s. The heavy bureaucratic burden placed on vendors made Ada too costly to ever become a significant factor in commercial applications. Although the eventual relaxation of governmental overhead made it possible to produce cheaper Ada products with faster time to market, much of the damage had already been done. Meanwhile the proliferation of inexpensive C compilers kept Ada from becoming widely used in academia, resulting in a flood of graduates accustomed to the C style of development who are less comfortable philosophically with - and more resistant to learning - Ada due to its syntactic heritage from ALGOL/Pascal.

Java – Java has enjoyed extraordinary popularity in desktop, web, and mobile device markets, and currently dominates those markets [2] while providing up to 10x improvement in programmer productivity. The abstraction, portability, scalability, and safety of Java are among its many attractive characteristics especially suitable to large, complex, and dynamic applications. However, Java has run into a major roadblock with regard to adoption across the broader spectrum of embedded development, particularly the very large class of applications that must operate on devices with tightly constrained resource budgets for footprint, execution speed, and response times. Ordinary Java typically runs 2-3 times slower than optimized C code, with a footprint many times larger, and with response times that are often sluggish and unpredictable with conventional garbage collection. Further, Standard Edition Java lacks portable mechanisms for low level device access. The Real-Time Specification for Java (RTSJ), introduced through the Java Community Process (JSR-1) as an official augmentation of Java, provides mechanisms for offering sub-millisecond latencies. However other issues that are important to the resource-constrained market, such as execution speed, footprint, and low-level device access, are outside the scope of the RTSJ. Any Java solution must address these issues to be acceptable to the resource-constrained community.

B#, the language introduced by de Champlain and Patrick, offers the following benefits to the resource-constrained computing market:

o compact language and efficient code generation
o familiar syntax (derived from C)
o full support for object orientation
o low level device access
o interrupt support
o simple type system
o portable multithreaded kernel abstraction

These are all important benefits for the embedded programmer. However, it would be a mistake to assume that these are the only benefits one would seek in an ideal solution. These features might be considered desirable or necessary, but not sufficient. A short list of other important characteristics one would seek includes:

o uses safe programming techniques
o is based on commercially dominant technology
o does not require “new language” evangelization
o is based on open specifications that promote standardization
o is already productized for ready market access
o does not need to build up an all new market ecosystem
o is scalable across multiple application dimensions

These benefits and more can be made available to the hard real-time and deeply embedded applications domain without resorting to a new programming language and VM architecture. While B# uses C as its starting point (and some clever readers have pointed out the irony that B# and C are equivalent in musical terms), one could argue that this approach reinvents the wheel. Object orientation has already been added on top of the C syntactic heritage, first in C++ and then in Java among others, and a portable threading abstraction is already available from Java.

There is a significant advantage to using Java as the baseline rather than C. The trick is to make it possible to use Java code in a way that hasn’t been possible in the past: a way that results in very small, very fast, very responsive applications, and offers portable means of accessing low level devices while also being interoperable with increasing levels of network-centric complexity. If such a solution were available, divergent branches such as B# would become redundant, and the yearnings of the resource-constrained computing community for an acceptable way out of the C quagmire finally would be satisfied.

The good news is that a resource-constrained solution based on the Java baseline is not idle speculation and wishful thinking. It exists today in the form of a technology called PERC Pico that is already licensed and in use today in limited release. Previous attempts at providing a hard real-time solution for Java have fallen short in that they have not resolved the common need of embedded developers to fit within strict timing and memory budgets, while at the same time introducing new complexities detrimental both to productivity and portability. PERC Pico has adopted valuable elements of those earlier attempts while discarding the problematic components.

It allows Java programmers to achieve execution speeds, memory footprint, and response times comparable to that available to C programmers while retaining many of the key benefits of full Java even for the most deeply embedded applications. Further, PERC Pico provides a portable threading model, safe memory management, and even the capability for dynamic loading, without resorting to a Java VM in the conventional sense. No doubt this will come as a relief to many embedded developers who, fairly or not, spontaneously cringe when they hear the term Virtual Machine.

In addition to being able to operate in a stand-alone mode “close to the silicon”, PERC Pico is also interoperable with full Java Standard Edition VMs, an ideal situation for the growing class of applications, such as network-centric distributed devices, that have both high functional complexity as well as the need for components with hard real-time constraints and a portable approach to low level device access. In the past, such applications would typically use Java for the complex application logic, but resort to C for the low level code, requiring problematic and inefficient cross-language interfacing. It is now possible to create low level components directly using Java code.

In the months following its initial commercial release in mid-2006, PERC Pico will be ported to all of the platforms supported by its sibling technology, PERC Ultra  - a soft real-time solution based on Java Standard Edition. In addition to “bare board” deployment, PERC Pico can be used with major RTOS platforms.

The guidelines for scalable Java development of real-time systems are openly available [2] and Aonix is actively involved with the current efforts of the Open Group and the Java Community Process to usher these specifications into standardization.

Kelvin Nilsen, Ph.D. is chief technology officer at Aonix North America