RAZOR WIT

Dick Pountain/16 February 2010 14:41/Idealog 187

Back in issue 180 I devoted this column to the revival of interest in parallel programming brought about by Intel's multi-core CPUs, and mentioned the Occam language tutorial that I once wrote for Inmos. Well, I recently received an email from Matt Jadud, assistant professor at Allegheny College in Meadville, Pennsylvania, who informs me that Occam not only isn't dead, but that he and colleagues use it to teach robotics to their students with great success. (He wants permission to reprint my tutorial, but the copyright position is unclear at present). Jadud and his group have written their own interpreter for a version of the language called occam-pi, which can be run from as little as 10 Kbytes of flash memory (http://transterpreter.org/) and they've ported this onto a number of microcontroller chips including the 8-bit Hitachi H8/3292 used in the Mindstorms RCX programmable LEGO brick, and Atmel's Atmega328 used in the Arduino  (http://arduino.cc/) control board, a product very popular with animatronic artists and hobbyists.

As an aside, my last foray into this sector was back in 1986 when I reviewed Micro-Robotics of Cambridge's Scorpion controller board in Byte magazine. Soon afterward my phone rang during dinner and it was the Henson Organisation from New York asking if I'd like to animate the faces of their Teenage Mutant Ninja Turtle characters. I had to politely decline as it would have involved moving to New York at two weeks notice (plus a *lot* of bluffing).

 Computers can be deployed in two quite different modes vis a vis the world. The first of these, most familiar to you, is where the computer builds a model of the outside world inside itself. This is most obvious in games, where you interact with those internal worlds via the screen, but spreadsheets and word processors equally mimic documents that would once have been scribbled with pen and ink on paper. Object-oriented programming is most appropriate for this role, enabling you to model those external objects explicitly and securely. 

 Embedded processing involves the exact reverse scenario, where a poor little computer has to interact with the big, cruel real world directly (through sensors, switches and motors) with little or no input from you. Maybe it's controlling your washing machine, or your car engine, or a robot. For this role you want a process-oriented language, one that concerns itself not with what exists but with what's *happening*. Occam is process-oriented in this sense, but actually it's more than a programming language, it's a concise and elegant general calculus for describing concurrency. It enables you to describe a problem in such a way that it could be computed by several different processors simultaneously, or by a single one imitating concurrency through time-sharing: it does that by abstracting the notion of communication between parallel processes.

 Maybe some PC Pro readers are old enough to remember former President of the USA Gerald Ford, of whom it was once cruelly said that he was too dumb to walk and chew gum at the same time. Well, conventional computer programs are dumb that way too, but not Occam. To describe walking you might say something like:

 PROC walk
 WHILE walking
 SEQ
    left.foot.forward
    right.foot.forward

 To chew gum you might say:

 PROC chew.gum
 WHILE chewing
 SEQ
    grind.jaw.left
    grind.jaw.right

 Now we can emulate a smarter sort of president thus:

 PROC smart.president
 PAR
     walk
     chew.gum

SEQ simply means execute the following processes one after the other, while PAR means execute them at the same time. There's another important construct called ALT, which says execute whichever of the following processes becomes ready first. Processes communicate values to each through named channels rather than variables, and the receiving process waits patiently for the sender to send. That covers about all the important concepts. David May, the principal architect of Occam, named it after the famous Oxford philosopher William of Occam whose principle called "Occam's Razor" pleads with us to cut out unnecessary stuff.

Occam was invented to be the lowest-level programming language for Inmos's Transputer, which had four high-speed hardware channels built right into the chip (after their parent chip perished these survived in the Firewire standard). Inmos failed to sell its model of communicating CPUs to the wider IT world because US firms at that time preferred the shared-memory model of concurrency where CPUs communicate by writing to the same memory locations, with all the consequent problems over locking and integrity that still bedevil us today. However Jadud's group has demonstrated that you can implement Occam on many processor/communication combinations: it would look neat on a multi-core Xeon with Intel's new Light Peak fibre-optics for channels, or equally on an Atom with USB 3.

But in the further future, if we want to build truly smart computers we'll need to combine the two modes of operation. Our brains maintain an internal model of the outside world even as our muscles and sensory organs propel us through it. To model that effectively, we need to be looking at adding Occam's elegant model of concurrency to a powerful object-oriented language like Ruby or even Java, in place of the clumsy and opaque tasking models currently employed. Oh to be a comp-sci postgraduate with a private income...