Re: occam and RT kernels

[Denis A Nicole <D.A.Nicole@xxxxxxxxxxxxxxx>]

On Sat, 30 May 1998, Lawrence Dickson wrote:

> Folks,
>    This is my belated 2 cents worth on the occam "toy" flurry of the
> last few weeks, which I am very glad to see has reinvigorated occam-com.
>    The "toy" terminology seems to refer to non-use in real world
> problems. The best answer I know of is that Daimler-Benz project that
> had a self-piloting car programmed in occam and running on the
> autobahn. The fact that projects of such complexity more or less
> arrange themselves in occam, while running against a low practical
> complexity ceiling in non-"live object" languages, is in itself an
> answer to Lamport's argument (as quoted).

Are Daimler-Benz still interested in occam?  Might they be interested in
using SPOC?

>    Here are some practical notions:
>    Has anyone out there started building occam compilers that work on
> standard commercial real-time kernels? These have a defined interface
> that may be a SUPERSET of what is needed to emulate the multitasking
> and multiprocessing primitives (i.e. in Inmos' old Compiler Writers
> Guide), they run on lots of different processors, and they claim to be
> snappy fast. I saw on http://www.windriver.com that there are third
> party Ada compilers and whenever I see Ada I ask, "Why not occam?"

I'm just starting to look at running SPOC occam on top of VXworks, to
support Autronica. Helpfully, the WindRiver development environment uses
gcc/gdb so source level interactive remote debugging should run on most of
their target architectures. 

>    WindRiver (VxWorks) may offer the quickest way to Mars, but to be
> fair here are two competitors: http://www.isi.com (pSOS) and
> http://www.atinucleus.com (Nucleus). They come up because all have been
> qualified to run on some third party disk driving software I am working
> on; so maybe these are the most willing to work with third parties like
> occam language developers, just in case something is needed (i.e. an
> ALT construct foundation?).
>    It would be quite a triumph to burst forth with a full occam
> compiler that would follow one of these RTOS's wherever it goes (and
> they have terrific real-time development tools too). According to my
> own experience doing something similar for the 8086, it would not be
> too great an effort---you guys have the compiler writing expertise, and
> the kernel interface is a small matter compared with that.

>    Second notion: occam by itself is too static. People want to run
> within an OS, which is dynamic in nature. Pardon the ad, but I showed a
> few years ago how you could have both worlds under not very onerous
> restrictions, and still rigorously control your resources. It was
> really pretty trivial, and I'm out of touch: but possibly this message
> needs to be got to people like Lamport?

Can you remind me of the reference?

>    Third notion: occam-EQUIVALENT designs, where the behavior of some
> simple hardware constructs (like FIFO memory reads/writes) can be
> proved equivalent to an occam program, are incredibly useful and could
> perhaps be to some degree automated?

Yes, hardware-software co-design seems quite good in occam; the main
competitor seems to be ADA/VHDL as a universal co-design "language"  So
really, we should be asking if occam can survive against ada95.

Denis A Nicole                      WWW:   http://www.hpcc.ecs.soton.ac.uk/~dan 
High Performance Computing Centre   Email: dan@xxxxxxxxxxxxxxx                  
University of Southampton           Phone: +44 1703 592703                      
UK.                                 Fax:   +44 1703 593903