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

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



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