NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/sys/transput/1213

Internet Message Format | 1992-11-18 | 3.7 KB

Path: sparky!uunet!know!cass.ma02.bull.com!mips2!news.bbn.com!usc!rpi!zaphod.mps.ohio-state.edu!darwin.sura.net!paladin.american.edu!news.univie.ac.at!hp4at!mcsun!sun4nl!dutrun!dutrun2!dutncp8!rob
From: [e-mail] (Rob Kurver)
Newsgroups: comp.sys.transputer
Subject: Re: IS Occam3 recursive?
Message-ID: <rob.722124411@dutncp8>
Date: 18 Nov 92 22:06:51 GMT
References: <rob.721665532@dutncp8> <[e-mail]> <[e-mail]> <rob.722034771@dutncp8> <[e-mail]>
Sender: [e-mail] (UseNet News System)
Organization: PACT, Delft, The Netherlands
Lines: 67
Nntp-Posting-Host: dutncp8.tn.tudelft.nl

In <[e-mail]> [e-mail] (Stephen Doyle) writes:

>In article <rob.722034771@dutncp8> [e-mail] (Rob Kurver) writes:

>>
>>The CSP paradigm as supported by Occam and PACT Parallel C is a very
>>powerful one, and is especially interesting with the support provided
>>by the transputer.
>>
>>Cheers. - Rob
>>

>Rob, you seem to have forgotten about INMOS ANSI C providing the same sort of
>CSP paradigm as your own, this obviously slipped your mind :-). I guess the
>difference boils down to whether you want an ANSI C validated compiler with
>functional additions for parallelism and communications or an ANSI C compiler
>with non-ANSI language additions for the same.

Steve, you seem to have forgotten about PACT Parallel C providing the same
sort of functional additions as your own, this obviously slipped your
mind :-).  It is my humble opinion that the CSP paradigm really should be
supported by language constructs.  Yes, use of the C language constructs
makes for a not strictly conforming program, so you'd better not use them
if you intend to port your code to a non-transputer.  Better not use
Occam in this case, either... :-)  The language constructs were added to
PACT Parallel C in an ANSI conforming manner - if you don't use them, you
have a fully validated ANSI C compiler.  (Please reply by email if you're
interested in the details of this.)

I guess the difference boils down to whether you want an ANSI C validated
compiler with functional additions for parallelism and communications or
an ANSI C validated compiler with the same functional additions for
parallelism and communications, with language constructs thrown in as
well.

>                                               I would argue (from customer
>feedback) that OCCAM tends to be used along with INMOS ANSI C as this
>provides you with a flexible environment for parallel/comms/sequential
>programming with excellent diagnostics at compile and run time.

We support mixing of Occam and PACT Parallel C object modules, for the
exact same reasons Inmos do.  No argument there.  Although customer
feedback indicates people eventually forget about Occam as they find
they can do everything they want in PACT Parallel C.

>Just to cloud the issue once more INMOS' soon to be shipping new optimising C
>compiler has a specific optimisation for tail call recursion i.e.

We decided against tail recursion optimization as it really doesn't improve
performance very much.  Of course, we continue to add optimizations and
improve our product as well, to make sure PACT Parallel C stays faster.
I've seen benchmark results of the beta version of your new optimizing C
compiler, and was relieved (although not surprised) to see PACT Parallel
C is still faster.

>Steve

Rob

P.S.: How come we don't here from Kirk Bailey about this recurring
      subject?  Are you still with us, Kirk?

--
     PACT                   Rob Kurver
    Foulkeslaan 87         [e-mail]
   2625 RB Delft     ph: [phone]
  The Netherlands   fax: [phone]