Lambda the Ultimate

It's a cute project, but does it put Smalltalk in a good light? It shows that Smalltalk dislikes retargeting. The guy fell back on a C compiler (the best on the PIC market, by the way). In effect his project confirms the ugly facts of embedded work: language designers (a) never consider real-time requirements and (b) fail to plan for back-end retargeting, leaving embedded workers stranded with their microprocessors. Look at how little discussion the recent post on real-time issues generated here on LtU.

Language designers seem obsessed with new and improved Virtual Machines, while neglecting the basic compilation and retargeting needs of embedded systems. I wonder, will the hype about ubiquitous computing evaporate once it is realized that embedded systems and VMs don't mix well? I'd trade all the VMs on the planet for a language with hard real-time guarantees, honest compilation to machine code, and easy back end retargeting.

To borrow from Feynman, "There's plenty of room at the bottom." Consider for example this success story coming as it does amidst all the PL groups talking about web services. Two guys in a garage came up with this "perfect" web services product without any help from the usual suspects.

I'll give Erlang credit for running on embedded hardware, but it too rides a VM and offers no hard real-time guarantees. These guarantees do require hardware support, but in the absence of that, a language could gracefully decay into soft real-time. Surprisingly, even stock PCs have enough hardware support: QNX will give you hard microsecond resolution on a stock PC. Too bad Linux won't!

I think it puts reuse and prioritization in a good light. He chose not to develop his own PIC-able subset of Smalltalk. Developing this subset of Smalltalk was not a priority for his business.

At the higher level, he stuck with Smalltalk, moreover he did not have to develop this one himself. He used Squeak.

A more interesting question might be: could he have reused the subset of Squeak, that the VM itself is implemented in, to retarget as a PIC compiler.

Language designers seem obsessed with new and improved Virtual Machines, while neglecting the basic compilation and retargeting needs of embedded systems.

I agree strongly with this, and you can probably find comments in LtU along these lines from me over the past year or so. However in this case we need to acknowledge the developer is not a language designer, he is a submarine designer.

Oh, I wasn't trying to implicate him as a "language designer." However he did try to retarget Smalltalk. It was only after failing that he re-prioritized. So my "language designer" remarks were aimed at the Smalltalk folks, and by extension, the whole lot worldwide.

What's interesting about the VM topic is that Giotto uses two of them, but for the dedicated purpose of providing hard real-time functionality. So I may modify my stance on VMs a bit. Of course one might as well call a hard real-time VM a microkernel. Probably the latter is a better name. At least it would be more traditional. Anyway I like what this Giotto research papers says:

The E machine proposes a paradigm shift in real-time programming: it permits the programmer to think exclusively in terms of environment time ("reactivity"), and shifts the burden of reconciliation with platform time to the compiler ("schedulability"). This paradigm shift is in line with the steady move towards higher-level programming abstractions. In fact, the E machine treats platform time as a resource in the way in which most high-level languages treat memory: the programmer assumes there is enough of it; the compiler makes sure there is enough of it (or fails to compile); the runtime system throws an exception in case the compiler was wrong (usually due to incorrect assumptions about the platform and possible contingencies).

Erlang's predecessor EriPascal might be of interest. That is Pascal extended with processes and asynchronous message passing. I think it was used for realtime programming because the manual specifies the running time for each primitive operation in microseconds.

Remind me to scan the EriPascal manual!

One thing that impresses me about EriPascal is that even back then they resisted any form of shared-state. Ultimately they had to support it as an optimization, but even then they used references with an extra indirection such that only one process could use shared objects at a time. If you send your reference to another process then you are transfering the right to use it, so it's just an optimization to avoid copying between the heaps. (IIRC.)

There's nothing quite like reading about old systems. It's remarkable that even with compuers a thousandth the power of ours they would seek solid designs and resist performance hacks, much more so than is common today. At least in the systems that are still remembered.. :-)

From the same paper, clarification on the VM topic.

E code (the code executed by the E machine) has strong theoretical properties...

It is the study of concepts such as time safety and environment/input determinedness that elevates the E machine from an intermediate language for compiling embedded code to a framework for evaluating embedded programming paradigms....

The E machine is a virtual machine. In an actual implementation of the E machine, E code need not be interpreted, but may be compiled into, say, C code, or even silicon. The difference between E code and equivalent C code lies in the programming discipline imposed by E code. In particular, the fact that E code relates to time strictly through the trigger queue makes time-safety analysis possible. Moreover, the overhead incurred by E code, rather than optimized C code, is minimal, because for code that supervises the timing and interaction of tasks, correctness (i.e., predictability) dwarfs performance as the critical design issue, even in high-performance control applications. For example, we have found that in helicopter control, the entire program contains less than 400 instructions of E code....

The number of implementations encourages my embedded programming heart.

We have three implementations of the E machine. The simplest one is written in C for Lego Mindstorm robots using the open-source LegOS operating system....The E machine implementation for the ETH helicopter [10] is written in Oberon using a custom-designed RTOS on a StrongARM embedded processor....The third implementation is in C under Linux using POSIX threads and semaphores. The E machine and each task runs in its own thread....The goal of the Linux implementation is to port it to the RTOS VxWorks, which also features POSIX threads, however, with real-time guarantees.

I'm going to chime in here, since I am the person in question...

PIC/Smalltalk wasn't a failure -- it did hard, real-time embedded PIC programming. I successfully interfaced it to a number of sensors and devices, include an ADXL202, a number of serial devices, and a pair of servos.

I stopped working on PIC/Smalltalk when I realized that continuing its development to support the new hardware features available on chips like the 16F87x series would end up being as big a project as MicroSeeker itself. I would have loved to keep working on it, because it was fascinating to work on, but I simply didn't have the time for it...

- Jon

Thanks for the clarification, Jon. Are you sure it was "hard" real-time and not "soft"? If so, very impressive!

You could certainly count cycles with it, and do work to the same level of timing precision that you would with any other PIC compiler.

I have a neat little PIC/Smalltalk demo board that uses the tilt sensor of an ADXL202 to control a servo -- the tilt sensor is read in the mainline code, and the servo is controlled by a FSM running off a timer interrupt. I'm not sure if that meets your qualifications for "hard" real-time, but it does mine.

Note that I have no training or real-world experience in embedded programming -- everything I know about it I've learned myself in the process of building my sub. That goes for electronics and machining as well. So my definition of "hard" may not meet the accepted standards of the word -- I really don't know...

- Jon

The terms "hard real-time" and "soft real-time" are very standard and commonly used. The presence or absence of an OS is an orthogonal issue and irrelevant to a hard/soft spec, though an OS might provide the software support required for one or both.

My original point is left standing, that languages offer poor retargeting support. Although you had success, it cost more time than you were willing to invest on a long-term basis.

The notion I entertain is that languages should not hard-code the back end, but target a virtual abstract machine defined in a user configuration file (PIC, x86, ARM, PowerPC, etc.). Maybe I'm dreaming but projects like ML-RISC and Typed Assembly Language give one hope.

The immature c-- project I've watched, but its breezy dismissal of ML-RISC seems trite and objectively inaccurate (such as the front-end language limitation claim). Actually ML-RISC advertises c-- as one of its users.

MLRISC Based Compiler

A long story would be cut short if MLRISC were just another abstract machine.

The key idea behind MLRISC is that there is no single MLRISC instruction set or intermediate program representation, but the MLRISC intermediate representation is specialized to the needs of the front end source language being compiled. The specialization does not stop there, but the:

• target instruction set,
• flowgraph, and
• entire optimization suite

Graphical Interface

All the major data structures and intermediate program states can be viewed graphically using daVinci and vcg. The following screen dumps are intended to represent the range of possibilities.

Of course none of this retargeting business covers hard real-time determinism. For that you need Giotto or equivalent.

The real woe to me is that language research groups are busy with their toy VMs, ignoring both issues: real-time and retargeting. Worse, their output can be outright antagonistic: JIT compilation is a huge no-no in real-time systems!

It might surprise LtU readers to learn how many devices use real-time software. Every day one stumbles across another. A recent Register article on cable modems mentions the use of VxWorks in a Motorola model. Real-time is everywhere, but you wouldn't know it from the research groups. Giotto was a happy surprise!