[comp.sys.transputer] C to occam translator

robert%zeus@swanee.ee.uwa.oz.au (Roberto Togneri) (09/24/90)

Hi,
	We are currenlt starting to use the Transputer Development System 
and feel that occam has more to offer than parallel C. However this means
that we will have to rewrite our algorithms from C to occam. This is ok for
the transputer/parallel specific stuff but given the
existence of fortran to C and pascal to C translator does anybody know of
a C to occam or even a Pascal to occam translator? 
	In fact I've seen very little on occam (there is no comp.lang.occam).
What is the prevailing attitude to transputers and occam? One reason we are
using occam is that it has the ALT operation which parallel C doesn't (appear)
to have. Any help appreciated.
--
Dr. Roberto Togneri		
Dept. of EE Engineering                 EMAIL: robert@swanee.ee.uwa.oz.au
The University of Western Australia     INTERNET: robert@zeus.ee.uwa.oz.au

rob@dutncp8.tudelft.nl (Rob Kurver) (09/25/90)

In <robert.654145325@zeus> robert%zeus@swanee.ee.uwa.oz.au (Roberto Togneri) writes:

>One reason we are
>using occam is that it has the ALT operation which parallel C doesn't (appear)
>to have. Any help appreciated.

If this is the main reason for using Occam, you may want to reconsider:
There do exist C compilers for transputers that offer the same parallel
constructs as Occam (par, alt, channel datatype) - my company offers one.

I don't want to plug a commercial product here, so contact me by email
(rob@pact.nl) if you're interested.

Cheers. - Rob

--
Rob Kurver                          rob@dutncp8.tudelft.nl
Computational Physics Group         rob@pact.nl
Faculty of Applied Physics, Delft University of Technology
The moon may be smaller than Earth, but it's further away.

geoff@hls0.hls.oz (Geoff Bull) (09/27/90)

In article <robert.654145325@zeus> robert%zeus@swanee.ee.uwa.oz.au (Roberto Togneri) writes:

>
>What is the prevailing attitude to transputers and occam? One reason we are

Occam is a real a______e for any reasonable sized program.
It is a really bad D unless your application is really well suited to the Occam
programming model and its not huge. Programmer productivity with Occam is about
10% of that with C. Do yourself a favour - leave Occam alone!

agn@research7.computer-science.manchester.ac.uk (Alvaro Garcia Neto) (09/29/90)

> Occam is a real a______e for any reasonable sized program.
> It is a really bad D unless your application is really well suited to the 
> Occam programming model and its not huge. Programmer productivity with Occam
> is about 10% of that with C. Do yourself a favour - leave Occam alone!

  You are entitled to a personal opinion, of course, but that is all it is.
Here at the Univ. Manchester, I've coded in occam a event-driven instruction
level-dataflow simulator.  Occam is not targeted at simulation, and the
110,000 lines of code make it too sizeable for my liking.

  Occam proved suffient for the project needs. In fact, if I had to start
again, I'd probably still do it in occam. 

  This is also only a personal opinion, of course...

'Alvaro
---------------------------------------------------------------------------
'Alvaro Garcia Neto      | JANET:    agn@uk.ac.man.cs.r7
Dept. Computer Science   | USENET:   ...!uunet!mcvax!ukc!man.cs.r7!agn
University of Manchester | BITNET:   agn%r7.cs.man.ac.uk@ukacrl.bitnet
Manchester, M12 9PL, UK  | Internet: agn%r7.cs.man.ac.uk@nsfnet-relay.ac.uk
---------------------------------------------------------------------------