Occam might be dead as an industrial language but its legacy lives on.
In attachment a screen dump from OpenVE, the GUI front-end for
We call this a pragmatic superset of CSP but the programming style is
similar. The current version is in C but C++ wrappers should not be a
The problem shown on the screen dump is a parallel matrix
even if OpenComRTOS was more designed for embedded applications (incl.
heterogeneous targets). You can see this in the topology diagram (our
standard demo mixes a Win32, a linux, a Leon 3 and a MicroBlaze). The
current implementation limit is 64K nodes, but granted, one would
have a dedicated tool for handling such large networks. Given that all
meta-data is in XML format, it doen't need to have a GUI. For
reasons, a better hardware would help as well, but if that' s
it's a matter of porting a linkdriver.
You can try out the WIN32 (and soon Linux) version for free by
it for free from our website. This version also emulates multi-node
---------------------- FROM : --------------------------
Skype me at: ericverhulstskype
Mob. +32 477 608339
"Push the button High Reliability"
"From Deep Space to Deep Sea"
From: Mailing_List_Robot [mailto:sympa@xxxxxxxxxx] On Behalf Of
Sent: donderdag 14 mei 2009 5:10
To: Ruth.Ivimey-Cook@xxxxxxxxxx; tjoccam@xxxxxxxxxxx
Cc: A.T.Sampson@xxxxxxxxxx; java-threads@xxxxxxxxxx; lewando@xxxxxxxxxxxxx
Subject: Re: JCSP, CSP Networking, and other some other points
Just forwarding a posting from Chris Jones on the above ...
From: "Jones, Chris C (UK Warton)" <Chris.C.Jones@xxxxxxxxxxxxxx>
Sent: 08 May 2009 13:46
To: 'Larry Dickson'
Subject: RE: JCSP, CSP Networking, and other some other points
Sorry I do not know how to send this directly to the mailing thingy.
You interest me greatly on the demise or potential future for occam.
We would still be using occam if we could. Many years ago, we
large code for simulating electromagneitc effects on aircraft -
lightning - into occam (it is about 140,000 lines now and was
100,000 then). We first analysed the main core of the algorithm in
course, we had transputers and the wonderful TDS.
It worked, was easy to maintain and continue to develop and we had
fundamental proof of the correctness of the implementation than we
dream of. Sadly, our T9000 machine never actually happened and we
parallel PowerPC processors with transputers handling the comms
Even more sadly, we had to rewrite our code back into the original
though by having gone through occam, it was much easier and bug free
the original had been. That code would still be occam if we had not
forced to reveert to Fortran for lack of occam implementations on
Even now, we would write some applications in occam were there a
way of programming a large parallel computer - we currently run 128
cores with a Quadrics switch. There are some issues
1. Lack of occam knowledge - actually this is far worse than it
We lack parallel computing knowledge at a fundamental level. Making
MPI libraries is not the same thing.
2. Personnally, I'd like to see a development systems akin to the
old TDS -
I am so old I actually do not like the modern programme writing
thousnads of interlinked filelets requiring a compendium of flow
dependency diagrams and spreadsheets to track effects.
I am actually in a day-mare trying to sort out such a problem at the
3. Access to standard libraries like LINPACK and NAG. This may be
problem, I haven't looked recently.
4. We would have to be able to identify an organisation that would
responsibility for supporting the compilers.
The lack of knowledge of occam is an interesting one in its own
we are moving towards this same situation on Fortran. My daughter
searching for a job in or around Edinburgh having completed her
degree. She found plenty of jobs requiring Fortran knowledge but
Java. Unfortunately the only programming language the university
teach was Java. I had a scan across a range on UK universities and
the same was generally true - even including the Opne University. I
the concluding that Sun is trying to do with Java what it did
for the early Sun workstations.
Edinburgh's stated justificaion was transportability, and then gave
homework involving proprietary and University only libraries!
As a matter of interest, we have the following numbers of people
Java isn't even on the list and is not going to be for the forseealbe
future. Even the new codes we are looking to develop over the next
will all be largely Fortran.
I would love to have transputers available again. The pain of
run let alone well on Intel or AMD multi-core processors is not
Occam would be used here if we could obtain from its use it's primary
benefit of programming large multi processor machines. I might even
my dream of hybrid data and functional parallelism. But this will not
happen till we have a reasonable way of launching code on multiple
processors from a perameterised architecture description - as we
the old TDS.
Dr Christopher C R Jones C.Eng. FIET
BAE SYSTEMS (Military Air Solutions)
Lancashire PR4 1AX
* tel: 01772 854625
* fax: 01772 855262
* e-mail: chris.c.jones@xxxxxxxxxxxxxx
BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace
Farnborough, Hants, GU14 6YU, UK Registered in England & Wales
No: 1996687 Exported from the United Kingdom under the terms of the UK
Export Control Act 2002 (DEAL No ####)
<OpenComRTOS Matrix multiplication.pdf>