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
kaiser@ananke.stgt.sub.org (Andreas Kaiser) (09/25/90)
In a message of <Sep 24 03:02>, Roberto Togneri (robert%zeus@swanee.ee.uwa.oz.au
) writes:
RT> We are currenlt starting to use the Transputer Development System
RT> and feel that occam has more to offer than parallel C. However this means
I wrote a cross compiler for parallel C (running on a PC) at the university of
Stuttgart.
The point is: I do not know about the status of the basis of this work, Johnsons
Portable-C-Compiler for the PDP-11. Until I know more, I cannot say whether it
is available or not.
RT> that we will have to rewrite our algorithms from C to occam. This is ok for
RT> the transputer/parallel specific stuff but given the
RT> existence of fortran to C and pascal to C translator does anybody know of
RT> a C to occam or even a Pascal to occam translator?
This is *impossible*. OCCAM does not allow neither recursion nor dynamic memory
management (heap) nor pointer types not structure/union types.
RT> What is the prevailing attitude to transputers and occam? One reason we are
RT> using occam is that it has the ALT operation which parallel C doesn't
RT> (appear) to have. Any help appreciated.
PAR, ALT, i/o and timer operations are included.
If you are interested, address your mail to
homeis@azu.informatik.uni-stuttgart.de
Gruss, Andreas
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!