🚀 go-pugleaf

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?

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.

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

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

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.

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.

:James

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

:James P. Salsman (jps@CAT.CMU.EDU)
-- 

:James P. Salsman (jps@CAT.CMU.EDU)

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

I have to take exception to this statement.  I might write my
concurrent programs in C, but that doesn't mean that I'm a "weenie."
I have found C to be far more capable for creating data abstractions
than occam.  For my money, any form of computer simulation is dependent
on 2 things: 1) Abstraction of the problem specification into structures
which mimic their "real-world" behavior, and 2) The creation of operators
for these strucutures.  This programming style is more easily
achieved with C, C++, or Ada, than with occam.

Occam is indeed a highly secure language.  As far as C goes, I would 
suggest that you not carry a gun unless you can shoot straight.
I've blown several holes in feet during the creation of multicomputer
software in C, but you overcome these "programming errors" by relying
on module testing and the employment of a software engineering design 
methodology for multicomputers.

I'm not sure I understand what is meant by your statement, "Occam...is more
effective than Ada."  I suppose in certain respects, like rendezvous,
or concurrency control in tasking, yes I agree.  But in other ways, 
like abstraction, data typing, data hiding, etc. occam don't quite cut 
the mustard.
>
>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.)
I agree with this.  Recursion is a very useful thing, and I'm not
the type to manage my own stacks of stuff (I'm generally too lazy or
stupid for this).  Unfortunately, inserting recursion into the occam
langauge would require the incorporation of dynamic memory allocation.
You need it to build call stack frames and the like.
>
>The macho way to do [dynamic memory allocation] 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.
Whatever turns you on.  I just use malloc.
>:James
-=-
Richard M. Stein (aka Rick 'Transputer' Stein)
Concurrent Software Specialist @ The Ohio Supercomputer Center
Trollius: The Official Multicomputer OS of the 1992 Olympic Games
Internet: stein@pixelpump.osc.edu, Ma Bell Net: 614-292-4122

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

> >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.)
> I agree with this.  Recursion is a very useful thing, and I'm not
> the type to manage my own stacks of stuff (I'm generally too lazy or
> stupid for this).  Unfortunately, inserting recursion into the occam
> langauge would require the incorporation of dynamic memory allocation.
> You need it to build call stack frames and the like.

I believe (and I'm sure I will be corrected if I am wrong :-) ) Scheme handles
tail recursion by re-using the existing stack frame, thus not using any more
memory than a single function call.  I think I saw this in Dybvig's book. 

Robert Rhode			|	"Today's champion
rhode@ricevm1.rice.edu		|    is tomorrow's crocodile shit."
bgr@uncle-bens.rice.edu		| Monty Python : Contractual Obligation Album

In article <275@oscsuna.osc.edu> stein@pixelpump.UUCP (Rick 'Transputer' Stein) writes:

> I have found C to be far more capable for creating data abstractions
> than occam.  For my money, any form of computer simulation is dependent
> on 2 things: 1) Abstraction of the problem specification into structures
> which mimic their "real-world" behavior, and 2) The creation of operators
> for these strucutures.  This programming style is more easily
> achieved with C, C++, or Ada, than with occam.

In Occam, abstraction is by processes.  Operators, then, are
messages sent (through channels) to the processes.  This
seems simple to me and fits well into your simulation model.

Which dialect of C do you use for multiprogramming?

:James
-- 

:James P. Salsman (jps@CAT.CMU.EDU)

For those who are primarily interested in exploring the concepts of
CSP (rather than producing blazingly fast programs on parallel hardware),
I believe the Icon programming language is worth looking at.  It's public
domain, well supported, well documented, portable to many machines,
written in C; it supports more than the usual complement of datatypes;
it supports coroutines.  It is very easy to implement (i.e., model)
all CSP operators in Icon.  (I will provide some illustrative code on
request -- amateurish, but then it's so easy that amateurs can do it!)

Since Icon is implemented in C, it's essentially a high-level C.  C programmers
should find it very easy to learn, and it lives very happily 
(though not exclusively) in Unix environments.  It seems to me that
Icon should be readily adaptable to real parallel hardware, but
I'm not sure whether anyone has done it.

Mike

Refs --  The Icon Programming Language by Ralph & Madge Griswold,
Prentice-Hall; The Implementation of the Icon Programming 
Language, same authors, Princeton University Press; multo
tech reports available from the Icon Group, Department of
Computer Science, The University of Arizona, Tucson, AZ
85721 USA

In article <5739@pt.cs.cmu.edu> jps@cat.cmu.edu (James Salsman) writes:
>In article <275@oscsuna.osc.edu> stein@pixelpump.UUCP (Rick 'Transputer' Stein) writes:
>
>> I have found C to be far more capable for creating data abstractions
>> than occam.  For my money, any form of computer simulation is dependent
>> on 2 things: 1) Abstraction of the problem specification into structures
>> which mimic their "real-world" behavior, and 2) The creation of operators
>> for these strucutures.  This programming style is more easily
>> achieved with C, C++, or Ada, than with occam.
>
>In Occam, abstraction is by processes.  Operators, then, are
>messages sent (through channels) to the processes.  This
>seems simple to me and fits well into your simulation model.
I agree.  The whole notion of simulation and concurrency does cleanly
abstract to processes and communication interfaces.
>
>Which dialect of C do you use for multiprogramming?
Well, I don't know if the Unidot C compiler available with the Trollius
OS is completely X3J11, but its a fair one.  I insert Trollius calls
into my software when message passing is needed or kernel services
are required.  All Trollius dependencies can be ifdef'd away if 
portability to sequential execution is a requirement.

But the great thing about Trollius is the kernel congruency between
"In the Box" (aka, Txxx) nodes, and the host node ("Out of the Box").
You can easily simulate and verify the logical concurrency of your
model in a shared-memory with Trollius, and then simply, without changing
a line of code, pump your software into a physically concurrent box of 
transputers.

If you do your design correctly, the shared-memory model can be debugged
with a standard (yucky) breakpoint debugger, and the Trollius state
command.  Its pretty clean.
>:James
-=-
Richard M. Stein (aka Rick 'Transputer' Stein)
Concurrent Software Specialist @ The Ohio Supercomputer Center
Trollius: The Official Multicomputer OS of the 1992 Olympic Games
Internet: stein@pixelpump.osc.edu, Ma Bell Net: 614-292-4122

In article <1948@harrier.ukc.ac.uk> arc1@ukc.ac.uk (A.R.Curtis) writes:

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

By "virtual memory" do you mean "allocatable heap storage"
or "memory paged out to disk"?  Occam can do both.  A
Transputer OS should provide a process for these functions.

> [In reply to the idea of using process abstraction for an
>        "allocation server" -jps]
> 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?

I can tell that you aren't an Occam programmer because you
don't know about CHAN OF ANY and PORT OF ANY -- these
protocols map everything back and forth into BYTEs.

In C, malloc returns a char pointer, while in the more
logical Occam, typelessness is declared as "anarchic
protocol."  I love that term!  "Anarchy" expresses what
dynamic allocation does to the semantics of the language
quite well.

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

Every heap must be allocated some time.  With Occam, you can
place your allocation process on a transputer that's next to
a disk (for swapping) or you can have a network of heap
processes, one on each processor.  In that sort of a system
you can have a huge virtual address space with a distributed
index.  Overflowed heap proceses can store on nearby
processors, and the "load" can be balanced or optimized
concurrently with the client processes.

> Why not let the system do the allocation for you?

Because it's just as easy to do it yourself.

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

It's hard for me to believe that you haven't heard of the
ANY protocol.  Why do you post if you don't know what you're
talking about?

:James

Disclaimer:  The usual.
-- 

:James P. Salsman (jps@CAT.CMU.EDU)

In article <276@oscsuna.osc.edu> stein@pixelpump.UUCP (Rick 'Transputer' Stein) writes:
> In article <5739@pt.cs.cmu.edu> jps@cat.cmu.edu (James Salsman) writes:

> Well, I don't know if the Unidot C compiler available with the Trollius
> OS is completely X3J11, but its a fair one.  I insert Trollius calls
> into my software when message passing is needed or kernel services
> are required.  All Trollius dependencies can be ifdef'd away if 
> portability to sequential execution is a requirement.

Okay, well, I think you program at a coarser grain of
parallelism than I do.  I'm mostly concerned with natural
language processing, information retrieval, multimedia
databases, and implementing local and wide-area networks for
those problems.  I also work on production system based
expert systems.

Serially, I learned BASIC, Z-80, C and Lisp, in that order,
but Occam is clearly superior for multiprocessing
applications.  Other parallel languages I've used are *Lisp
and PARIS/C (on the Connection Machine.)

Perhaps in a language debate like this we should talk about
the applications involed.

:James
-- 

:James P. Salsman (jps@CAT.CMU.EDU)

In article <5751@pt.cs.cmu.edu> jps@cat.cmu.edu (James Salsman) writes:
>In article <1948@harrier.ukc.ac.uk> arc1@ukc.ac.uk (A.R.Curtis) writes:
>
>> occam has compile-time allocated memory. It deals solely with *real*
>> memory, and none of this nice run-time virtual memory.
>
>By "virtual memory" do you mean "allocatable heap storage"
>or "memory paged out to disk"?  Occam can do both.  A
>Transputer OS should provide a process for these functions.
>

By "virtual memory",  *I* would mean "as much memory as my process
requires, even if this is more than is physically attached to the
processor".  I, for one, would be interested in seeing how you would
implement paged memory on a processor without an MMU in any way, shape
or form.  By "Transputer OS", I presume you mean a glorified loader,
like CP/M or MS/DOS, which falls over when the user process falls over.

>> [In reply to the idea of using process abstraction for an
>>        "allocation server" -jps]
>> 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?
>
>I can tell that you aren't an Occam programmer because you
>don't know about CHAN OF ANY and PORT OF ANY -- these
>protocols map everything back and forth into BYTEs.

CHAN OF ANY does not "map everything back and forth into BYTEs".  It's
just a method of switching off the compiler's checking on the types of
data sent over a channel.  You can (probably) get away with treating it
as a CHAN OF BYTE over a physical link, but over a soft channel, all
sorts of things at the implementation level (such as block copies) mean
that this just doesn't work.  This is not a problem with the
implementation of soft channels -- semantically there is no obligation
for this to work.

Treat CHAN OF ANY as a bag on the side, there to allow easier
conversion of occam 1.  In those days, all you had was a CHAN, and you
sent an integer tag to indicate what was coming next.  Now we have
tagged protocols to take care of that sort of thing for us, and check
for silly errors too, we don't need to resort to this low level.

(Aside:  I happen to know that Tony has been programming in occam since
the occam 1 days.  He certainly has heard of CHAN OF ANY.)

>> [Tony made some comments about having to allocate all memory
>> at compile time]
>
>Every heap must be allocated some time.  With Occam, you can
>place your allocation process on a transputer that's next to
>a disk (for swapping) or you can have a network of heap
>processes, one on each processor.  In that sort of a system
>you can have a huge virtual address space with a distributed
>index.  Overflowed heap proceses can store on nearby
>processors, and the "load" can be balanced or optimized
>concurrently with the client processes.

Ah, by swapping, you meant moving unused bits of heap away.  You
certainly can do this, but you write the code to do it.  What I want is
to be able to run arbitrary-sized programs on processors with finite
amounts of memory.  This might mean swapping some of the code out as
well.  Not so easy.

On machines which support paging and swapping, this sort of support is
built into the operating system.  (On future Transputers, it might be
built into the chip.)  It certainly isn't, and can't ever be, part of a
programming language.  The whole point is to hide such mechanisms from
the programmer.


Going back to the heap allocation problem, Tony was right when he said
that you couldn't do it generally.  There are two cases; single
processor, and multiple processor:

(1)  You place the heap in the memory of the process that is using it,
     and use sequential routines called from the user process to manage
     it.

     In this case the heap management package consists of routines to
     allocate and free blocks from a large array.  The array is passed
     to the heap routines so it can write information into it about
     block sizes and utilisation.

     So, your routine asks the heap manager for a block of a certain
     size, it returns an index into the array, and you RETYPE the array
     FROM that index FOR the size for the object you wish to put into
     the heap.  However, beware, because RETYPE will cause a run-time
     error if you don't have the alignment right.  You can't check for
     alignment -- that's a low-level detail unconnected with occam
     semantics.  Possibly this alignment problem is an implementation
     problem with the current compiler.

     The best bet is probably to use an array of INTs because they're what
     the processor deals with best (in occam 1 it's all you had :-).
     But remember the size of an INT is processor dependent, not an
     absolute value, so don't insert any magic numbers in your code
     when you're trying to work out how much heap space you will need
     for, say, an array of BYTEs.  None of this is very elegant.

     Each process therefore has its own heap, allocated at compile time.
     The advantage of having a heap is that you don't have to make
     decisions about the balance of memory utilisation between processes
     until run-time (when they are made for you by the inputs to the
     task).  If each process has its own heap then this automatic
     balancing is lost, and the overhead of a heap is wasted -- just
     give each process a fixed-size array (this is what you are
     effectively doing).

     Actually, the heap could be shared between processes on the same
     processor, and requests for part of it communicated to a heap
     management process; the manager could return an index into the array.
     However, this isn't occam.  It isn't possible to check statically that
     processes are not accessing memory outside their allotted areas,
     i.e. usage checking would have to be turned off at compile time.


(2)  For the multiple processor case, a memory server processor could be
     implemented.  In this case, you add data to the heap, and collect
     data from it via communication over channels.  You'll need a
     tagged protocol with tags for all of the different types of object
     you will want to put in the heap.  All reads and writes require
     the overhead of channel communication, and the heap manager needs
     database management capabilities (to avoid problems caused by
     parallel updates, if more than one process uses the heap).

     However, because the tags are application dependent, you need to
     write a dedicated memory-server for each application.  Not a
     general solution.

>It's hard for me to believe that you haven't heard of the
>ANY protocol.  Why do you post if you don't know what you're
>talking about?
>
>:James P. Salsman (jps@CAT.CMU.EDU)

He does know what he's talking about, it's just that he's not prepared to
make the compromises and take the short cuts you suggest when writing
programs.

Don't use CHAN OF ANY because you are too lazy to define a tagged protocol.
It is interesting to note that Geraint Jones' and Michael Goldsmith's
book, "Programming in occam 2" devotes about half a page to CHAN OF ANY
(it has over 300 pages in total), and it says (page 59) "... the only
circumstance in which internal anarchic channels are reasonable is when
simulating a piece of hardware for testing the process which will drive
it." The INMOS "occam 2 Reference Manual" takes a similar line -- it
talks about communication with an "alien process".  Its description of
the retyping is only valid for physical links.


There are a lot of problems still to be solved in this area, and we need
semantically secure solutions.  However, it is good to see some support
for occam from the other side of the Atlantic!



	Godfrey Paul