Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!oscsuna.osc.edu!pixelpump.osc.edu!stein
From: stein@pixelpump.osc.edu (Rick 'Transputer' Stein)
Newsgroups: comp.sys.transputer
Subject: Re: choosing parallel languages
Message-ID: <276@oscsuna.osc.edu>
Date: 3 Aug 89 16:34:48 GMT
References: <8908011650.AA12679@kanga.cs.umass.edu.edu> <5726@pt.cs.cmu.edu> <275@oscsuna.osc.edu> <5739@pt.cs.cmu.edu>
Sender: news@oscsuna.osc.edu
Reply-To: stein@pixelpump.UUCP (Rick 'Transputer' Stein)
Organization: Ohio Supercomputer Center
Lines: 39

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