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

[Lawrence Dickson <tjoccam@xxxxxxxxxxx>]

Thank you, Matt. I'm now getting some more posts coming in on my
sister's slow connection. Whether they will all come is anybody's
guess. So anybody who doesn't get a response please forgive me.

ProcessJ does sound interesting, and I will have to look at it in
greater detail. A vote for semicolons, I guess... ;-) Is there any way
to restrict C, with or without MPI, so that it doesn't have dynamic
constructs like malloc?

Larry

On 8/2/09, Matt Pedersen <matt@xxxxxxxxxxxxxxxxxxxx> wrote:
> Larry,
>
> we are working on a 'new language' currently called ProcessJ which is
> occam with a java syntex - semicolons, { } and all the stuff that people
> 'like' in a language - its is non oo, process oriented and pretty much
> like oocam - we are working on code geenrators to translate ProcessJ to
> occam-pi, java/JCSP and C with MPI.
>
> with a little luck we should be able to talk about it some more at
> this years CPA.
> http://www.egr.unlv.edu/~matt/research/Joccam-content.html
>
> (not it was called Joccam to begin with and was recently renamed to
> ProcessJ) - there is more info to come shortly!
>
> Matt
>
> +-----------------------------------------------------------------------+
> | Jan 'Matt' Pedersen, Ph.D.                 Office: TBE B384           |
> | Assistant Professor                        E-mail: matt@xxxxxxxxxxx   |
> | School of Computer Science                 Phone : +1 (702) 895-2557  |
> | University of Nevada at Las Vegas          Fax   : +1 (702) 895-2639  |
> | Las Vegas, NV, 89154-4019                  Home  : +1 (702) 792 2580  |
> |             Home Page: http://www.cs.unlv.edu/~matt                   |
> +-----------------------------------------------------------------------+
>
> On Sun, 2 Aug 2009, Larry Dickson wrote:
>
>> 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>
>>
>>
>>
>
>