[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: occam and RT kernels
On Sat, 30 May 1998, Lawrence Dickson wrote:
> 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
> 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