[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: JCSP, CSP Networking, and other some other points

Dear Chris,

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 OpenComRTOS.
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 multiplication
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 need to
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 performance
reasons, a better hardware would help as well, but if that' s available,
it's a matter of porting a linkdriver.

You can try out the WIN32 (and soon Linux) version for free by downloading
it for free from our website. This version also emulates multi-node targets.

Best regards,

Eric Verhulst

----------------------  FROM : --------------------------
   Skype me at: ericverhulstskype
   Mob. +32 477 608339
   "Push the button High Reliability"
"From Deep Space to Deep Sea"

-----Original Message-----
From: Mailing_List_Robot [mailto:sympa@xxxxxxxxxx] On Behalf Of P.H.Welch
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 rewrote a
large code for simulating electromagneitc effects on aircraft - particularly
lightning - into occam (it is about 140,000 lines now and was proably about
100,000 then).  We first analysed the main core of the algorithm in CSP.  Of
course, we had transputers and the wonderful TDS.
It worked, was easy to maintain and continue to develop and we had more
fundamental proof of the correctness of the implementation than we can now
dream of.  Sadly, our T9000 machine never actually happened and we accepted
parallel PowerPC processors with transputers handling the comms instead.
Even more sadly, we had to rewrite our code back into the original Fortran,
though by having gone through occam, it was much easier and bug free than
the original had been.  That code would still be occam if we had not been
forced to reveert to Fortran for lack of occam implementations on other
commodity processors.

Even now, we would write some applications in occam were there a reasonable
way of programming a large parallel computer - we currently run 128 quad
cores with a Quadrics switch.  There are some issues

1.  Lack of occam knowledge - actually this is far worse than it sounds.
We lack parallel computing knowledge at a fundamental level.  Making cals to
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 pardigm with
thousnads of interlinked filelets requiring a compendium of flow charts and
dependency diagrams and spreadsheets to track effects.
I am actually in a day-mare trying to sort out such a problem at the moment.

3.  Access to standard libraries like LINPACK and NAG.  This may be a solved
problem, I haven't looked recently.

4.  We would have to be able to identify an organisation that would take
responsibility for supporting the compilers.

The lack of knowledge of occam is an interesting one in its own right since
we are moving towards this same situation on Fortran.  My daughter has been
searching for a job in or around Edinburgh having completed her physics
degree.  She found plenty of jobs requiring Fortran knowledge but none for
Java.  Unfortunately the only programming language the university would
teach was Java.  I had a scan across a range on UK universities and found
the same was generally true - even including the Opne University.  I draw
the concluding that Sun is trying to do with Java what it did decades ago
for the early Sun workstations.
Edinburgh's stated justificaion was transportability, and then gave out
homework involving proprietary and University only libraries!

As a matter of interest, we have the following numbers of people profient in
respective languages:

Fortran   3
C         5
C++       1
Matlab    2
Tcl       3
PERL      1
Python    1
Pascal    2
Occam     1

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 5 years
will all be largely Fortran.

I would love to have transputers available again.  The pain of making codes
run let alone well on Intel or AMD multi-core processors is not pleasant.
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 realise
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 could from
the old TDS.


Dr Christopher C R Jones C.Eng. FIET
Technologist Consultant
BAE SYSTEMS (Military Air Solutions)
Warton Aerodrome
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 Centre,
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 ####)

Attachment: OpenComRTOS Matrix multiplication.pdf
Description: Adobe PDF document