next up previous contents index
Next: The Dreams System Up: Background Previous: Dreams   Contents   Index


Considerations for Real-Time

Although the advantages of an object oriented approach are well documented, there have been some very real problems making use of this approach in embedded real-time systems. Many object oriented systems, such as Smalltalk [Gol83] and Flavors [BL87], make use of sophisticated development environments that are difficult to eliminate after the software has been developed. Others, like Flavors, require extensive breadth first searches through a tree structured hierarchy of multiple inheritance to determine the applicable method to employ. Some require elaborate list structures and the overhead of garbage collection [Ric87]. Mark and sweep garbage collection causes a real-time system to go into a petite mal epileptic seizure: until the garbage collection finishes, no other processing can go on [Knu68, pp 406-422, 594]. This is usually unacceptable. Ephemeral, or generation scavenging, garbage collection [Jac90] introduces shorter delays, but can still destroy deterministic timing.

Alternative attacks to this are seen in C++ and Ada. Both of these languages use object oriented techniques, but their power is somewhat lacking because they must determine at compile time which definition of an object is to be visible at run time. Some advanced techniques in object oriented programming cannot operate with this restriction.

To be applicable to a real-time environment, an object oriented system should be deployable on a minimal platform. To meet the demands of real-time operation, it should not make use of garbage collection or extensive method searching. It would be most desirable if the overhead to activate a particular object was fixed and determinable. To be truly flexible, it should not require that method determination be performed at compile time.

Dreams is written in Forth, and is therefore readily targetable to a wide range of deployment platforms. Forth is implemented on some of the largest and fastest computers in the world [Dor86,Dor89], and also on some of the smallest and most humble microcontrollers available [Dun86]. It is the machine language of a new generation of RISC machines that are particularly well suited to real-time applications [Dun89,Har88,Koo86]. Due to Forth's ability to extend the compiler, the implementation of dreams is very straightforward, thereby easing portability and maintainability.

Dreams makes use of a dynamic binding mechanism that has a fixed and known overhead going into and coming out of a dream. Dynamic binding permits powerful late binding programming strategies to be used without the associated cost of run-time method searching overhead. Dreams was designed for real-time and written in a language that was designed for real-time. Forth is now directly executable as the machine language of several high performance RISC processors. At least one of these processors is available as a component of a standard cell library, thereby making incorporation of that processor into a custom integrated circuit quite straightforward and routine. This is the kind of deployment platform needed for many embedded applications.

In most cases, the overhead of dynamic binding should actually be less than the alternative overhead of basing all local instance variables on a pointer. The source code written using dreams will be devoid of cryptic pointer qualified variable references; it will use variables in the conventional manner. Indeed, dreams may even be used to retrofit existing code to a multiply instantiated application, even where that code's use of variables would normally prohibit its use in such applications. This is often the case when re-using code in a re-entrant multitasking application if that code was originally developed under a single-tasking, non-re-entrant assumption.


next up previous contents index
Next: The Dreams System Up: Background Previous: Dreams   Contents   Index
Robert J. Brown
1999-09-26