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 ####)
Attachment:
OpenComRTOS Matrix multiplication.pdf
Description: Adobe PDF document