Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcvax!ukc!harrier.ukc.ac.uk!arc1
From: arc1@ukc.ac.uk (A.R.Curtis)
Newsgroups: comp.sys.transputer
Subject: Re: choosing parallel languages
Message-ID: <1948@harrier.ukc.ac.uk>
Date: 2 Aug 89 16:33:10 GMT
References: <8908011650.AA12679@kanga.cs.umass.edu.edu> <5726@pt.cs.cmu.edu>
Reply-To: arc1@ukc.ac.uk (A.R.Curtis)
Organization: Computing Lab, University of Kent at Canterbury, UK.
Lines: 79

In article <5726@pt.cs.cmu.edu> jps@cat.cmu.edu (James Salsman) writes:
>In article <8908011650.AA12679@kanga.cs.umass.edu.edu> oskard%kanga@cs.umass.edu (DAVID OSKARD) writes:
>> 	If you had the chance to do it all over again, would you buy
>> Occam or one of the third party compilers for the Transputer?
>

I wouldn't buy transputers...

>Occam is far superior for multiprocessing than any serial
>language (such as C) and it's model is much more safe and
>effective than Ada's.  The problem is that the C-weenies
>of the world have not yet aquired the brain capacity to
>understand the beauty and functionality of Occam -- yet.
>

occam's model is far too simple. The reason the model is safer is
that it has so little in it. I have acquired the brain capacity to
understand occam, and I can see virtually no functionality. And as
for beauty...

>The only thing I would change is to allow value functions
>to be recursive and specify that tail recursion is properly
>dealt with (as in Scheme.)
>

occam has compile-time allocated memory. It deals solely with *real*
memory, and none of this nice run-time virtual memory.

>> To me it seems that the lack of support for data structures in Occam
>> is in itself reason enough to consider other possibilities. Is this
>> really as big a deal as it seems?  How have you gotten around Occam's
>> limitations?
>
>Hey!  How about "Procedural Abstraction?"  What a concept...

What do you mean by "Procedural Abstraction"? Having procedures? I
don't really think this is a great leap forward...

>
>The lack of dynamic memory allocation in Occam is easily
>overcome by allocating a large array, and using procedures
>for allocation and freeing of individual elements.  If you
>do it right, and know how to use the retyping system, you
>can create a generalized heap storage system, where the same
>memory is used to store many types of data.
>

Ok, so how do you provide a memory allocation server to handle
completely arbitrary types? You can't, can you? But I can do this in
C, can't I?

Also, allocating a lump of memory yourself as the heap has nasty
drawbacks. The size depends on how much memory is on the processor.
Less memory, less space - how do you allocate according to memory
availability? You can do it manually, but that stinks.

It means that all of this lump has been removed from the available
pool of memory. Why not let the system do the allocation for you?

>The macho way to do it is to create a tagged protocol
>channel coprocess that allocates memory and handles access
>and (de)allocation functions.  Then, you can place the
>process on whatever processor has the RAM (or the disk) for
>the data that you're storing.  This is a cool programming
>technique, as well as a neat abstraction.
>

Yes, but it can't work in the general case. You can't provide a
server which will (de)allocate any arbitrary structure for you. You
run up against the protocol problems of occam at high speed there,
and the results are messy, because you can't specify arbitrary data
types.

>Disclaimer:  The University doesn't always agree with me.

And neither do I...


Tony Curtis