A few of you may have tried Smalltalk-80, but I bet most have cut their teeth on C, C++, and Java. Smalltalk was one of the first object-oriented programming (OOP) languages and it brought an interactive development environment to the masses. Smalltalk had a host of target audiences from children to robotics, and there is still a very active community using Smalltalk. You can find out more at Smalltalk.org and WhySmalltalk.com. In addition, you can download a fully operational version of Smalltalk from Squeak.org.
But we are here to talk about embedded applications. Esmertec has taken a chance with Smalltalk. The language implementation has a few differences from Smalltalk-80 that I will discuss later, but they are relatively minor for someone with Smalltalk expertise. New OSVM developers will probably not even realize there are differences.
The biggest change is in the runtime. Smalltalk was initially designed for Xerox Star systems, a precursor to the Apple Macintosh. Graphics were hot and much of the overhead associated with Smalltalk was due to the graphics. Esmertec discards the overhead, but retains a graphical development interface through the use of Eclipse (Fig. 1).
The Eclipse-based integrated development environment (IDE) has an OSVM plug-in that provides a Smalltalk (Esmertec's variant) editor, syntax checking, and compiler support. Much like a conventional programming environment, the heavy lifting is done within Eclipse. This keeps the size of the virtual machine (VM) down. Eliminating floating point support also helps.
The OSVM virtual machine is about 32 kbytes and the real-time operating system (RTOS) that can be used with it is only 2 kbytes. OSVM will run on top of commercial RTOS products as well. The two target environments right now are standard ARM microcontrollers and the x86 under Windows and Linux.
The other big change from the conventional Smalltalk development environment for OSVM is what the environment knows about itself.
OSVM: A Reflection Of Itself Reflection is the term normally used to describe how an application knows about itself. Java provides some support, but not at the same level as Smalltalk. OSVM actually falls between conventional Smalltalk and Java. An OSVM application does not have the same capability as a conventional Smalltalk system, which can examine classes and create new classes. However, the use of this type of information is maintained and used within the OSVM Eclipse plug-in.Reducing reflection in OSVM has two consequences. First, it significantly reduces the size of the virtual machine and the complexity of the runtime. It is also a feature that has little use within an embedded system. Second, it simplifies the overall system, making it easier to understand. Few really appreciate or utilize conventional Smalltalk's meta data.
OSVM: Embedded Smalltalk The OSVM virtual machine is designed with TCP/IP networking in mind. A TCP/IP socket is the link between the Eclipse plug-in/IDE and the virtual machine. A developer can edit source files or link to a virtual machine. In the latter case, class definitions are automatically downloaded as required. Only those classes that are needed will be downloaded unless the VM has them already.A developer interacts with the VM using a command window. Expressions can be entered and evaluated by the VM. Currently only one VM can be connected to Eclipse at a time, but it is possible to disconnect from a running VM and reconnect to another. The system will support multiple VM connections in the near future.
Disconnecting and reconnecting has limitations, as the debugger is tied to the connected VM (Fig. 2). Typically a disconnected VM will run one or more tasks that have been debugged while the connected VM runs applications that are being developed.
The connection is the key difference between the typical Java VM development environment and OSVM. One thing you notice with an OSVM task list is that there are half a dozen tasks always running, including the debugger support and the IDE support. The latter handles downloading and updating for classes. A Java VM is typically started with a set of classes, debugged, and then the whole thing is terminated. It's possible to develop a Java VM environment that is more dynamic, and frameworks like OSGi provide this type of dynamic loading service. Unfortunately, these kinds of frameworks tend to be a bit more complicated to work with than an OSVM where it's second nature.
Smalltalk 101 A complete overview of OSVM Smalltalk is beyond the scope of this article and it is much better to download the free evaluation version from Esmertec. The documentation is good and much more manageable than a full-blown Smalltalk system. Still, here is a short overview for those interesting in getting their feet wet.Method call parameters follow an object reference and a method name. A colon after the method name indicates a parameter follows as in:
anObject setAge: 12
Multiple arguments have additional keywords followed by a colon as in:
anObject setMessage: 'Hello world' andList: #(1 2 3).
versus Java and C++ that use parenthesis and commas. A period terminates an expression, but often a method returns the initial object reference so methods can be concatenated as in:
anObject setAge: 12
setMessage: 'Hello world' andList: #(1 2 3).One of the biggest differences between it and more conventional statement-oriented languages like Java and C++ is the concept of a block. In Smalltalk, a block is a first class item. This changes the way conditionals and loops work. Instead of being a special statement, they are method calls to boolean objects. A block is a sequence of expressions within square brackets as in:
\[ a + 1 \]
A simple conditional expression looks like:
aBoolean ifTrue: \[ a + 1 \] ifFalse: \[ a - 1\]
Blocks implement looping methods as in:
\[ a := a + 1 \] repeatWhile: \[ aBoolean \]
It takes some getting used to but it quickly becomes natural for most programmers. Blocks are actually more powerful and they can take parameters as with class methods.
OSVM blocks have some limitations that conventional Smalltalk blocks do not have. In particular, blocks cannot be returned and blocks cannot be assigned to class variables. These and other restrictions essentially mean blocks can be passed down the stack when methods are called, but they cannot be returned beyond the context in which they are defined. This provides the designers at Esmertec with the ability to perform significant optimizations, making the system fast but flexible.
It's possible to use other mechanisms to get around this restriction, but with the additional overhead. It seems to be a very reasonable tradeoff. Even the restricted block semantics provide a more powerful approach to programming than that provided by Java or C++.
OSVM provides multiple threads, synchronization objects, and advanced error handling features. The base system also supports TCP/IP with sockets, DNS support, and so on. All the features can be easily scanned and understood in a day. Very few embedded languages can make that claim.
Efficiency? OSVM is currently implemented as an interpreter. However, the crew working on it had a hand on Sun's Java Hot Spot JIT (just-in-time) compiler, so expect to see fast, native code in the future. Even so, depending upon the application, an interpreter can provide the kind of performance necessary for many control and monitoring applications.So why change? That is going to be a tough question to answer. OSVM offers an interactive environment for both development and deployment that is very different from current systems. An OSVM system is not designed to go down. It is designed to run continuously even when making major changes to the applications that are running. This is possible on other systems by changing program files when an application is not running. It is even possible to download new Java class files to perform the same kind of operation, but neither has the flexibility or power of an OSVM change. Likewise, the type of interaction and control OSVM brings to the table is unmatched by existing environments.
OSVM provides access to memory-based peripheral interfaces. It can also access system primitives so even an interpreted environment can be utilized on a high-performance system where low-level support is provided by device drivers written in assembler or C.
Obviously shifting from an existing development environment to OSVM will be a significant change. It may be viable to run OSVM on top of an existing system, and it will be workable for new projects. Switching an existing system to OSVM is definitely nuts—unless time is not an issue.
OSVM will be very different for most developers. Only Forth or interactive Basic developers have had this type of support of late. The interaction is addicting and powerful, but it remains to be seen whether Esmertec can convince developers to switch. It will be a slow process. So keep your eye on Esmertec and OSVM. It might be time to switch.
www.eclipse.org
Esmertec
www.esmertec.com
OSGi Alliance
www.osgi.org
Smalltalk.org
www.smalltalk.org
Squeak.org
www.squeak.org
Why Smalltalk
www.whysmalltalk.com