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

son of occam (was: Re: JCSP, CSP Networking, and other some other points)

Hi all,
I'm going to trail off this thread and change its name because I'm changing the subject a bit. Everybody seems to agree that occam is "dead" but is still the best way to do things, which is of course ironic. I have long wanted to move it in a more practical direction while keeping its cleanness and simplicity (NO OO), and now may have a business route to that (more on that later). I want to get some opinions from the list.
(1) What should it look like - traditional occam (Python, etc) with indents and significant line-feeds, or C (java, etc) with semicolons?
(2) What should an associated scripting language look like? I want to control everything from soup to nuts ultimately, which means bootup too.
(3) What should get first attention as the analogue of the hardware link? USB? TCP/IP?
(4) Is anyone doing a flavor of Transterpreter or similar project but retaining the full-interrupt Priority 0 of the Transputer? 

Larry Dickson


On May 18, 2009, at 6:11 AM, Eric Verhulst wrote:



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
problem.
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 : --------------------------
  Eric.Verhulst@xxxxxxxxxxxxx
  Skype me at: ericverhulstskype
  Mob. +32 477 608339
  "Push the button High Reliability"
  http://www.altreonic.com
-----------------------------------------------------------
"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 ; 
occam-com@xxxxxxxxxx
Subject: Re: JCSP, CSP Networking, and other some other points


Hi,

Just forwarding a posting from Chris Jones on the above ...

Peter.

---------------------------------------------------------------------------
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


Larry,

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
though:
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.


Regards,
Chris.



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