[comp.sys.transputer] Introductory occam language texts etc.

stein@dhw68k.cts.com (Rick Stein) (11/19/88)

In article <1389@thumper.bellcore.com>, Ravi Masand writes:

>Questions: Has anyone out there worked with the transputer 
>in a language other than Occam?  How has it worked out?
>Is Occam really mandatory to use the CPU to its fullest?
>And anyone know of a good book reference to pick up Occam
>in a hurry??


There are at least 2 "C" compilers available for transputer:
One from Logical Systems (Portland, OR), and the other from
3L Ltd. (England).  Both give comparable performance, although
from prior postings to this group, I believe that LSC generated
more optimal code.  I have the 3L C compiler.  Nearly ANSI
(latest revision is 2.0.2).  You can get it from Microway.
3L also has FORTRAN and PASCAL compilers available.  All there
compilers come with a modest utility suite to assist configuring
multicomputer networks, etc.  I don't know if 3L's stuff is
available on anything other than PC and Macs.  Perhaps SUN, but
I'm not sure.

If your into full blown applications, you'll need an OS.
Trollius is an ideal start.  A very robust kernel which is
small, highly functional, and efficient for first-generation
multicomputer systems based on the Inmos silicon.

[Opinion:
Occam has its drawbacks as a HLL.  Among these are static
bindings, no dynamic memory allocation support, incapable of
creating hierarchical ADTs (abstract data types) like you
get in C, C++, PASCAL, ADA, etc.  It also does not support 
recursion.  In short, its kinda' like the
FORTRAN with some constructs for concurrent context
specification.  Yet, if your into a real-time mode for small
applications, like a transputer-base laser printer controller,
or an ignition system for a car, etc,  I don't think you can 
beat the absolute, low-level control one gains with occam +
transputer.  Unless you're into assembly stuff :-)
BTW, all this stuff is covered in my November, 1988 Byte
article, "T800 and Counting."
]

Among the major problems lacking with concurrent software
systems development for transputers is the lack of a good
debugger.  Now, the Express system from Parasoft has a thing
they call NDB (I think it's an adaptation of dbx) which provides
for symbolic debugging.  I don't know what state of development
its currently in. :-(

[Opinion:
I think something like T.A. Cargill's Process Inspector would be
a fantastic aid for multicomputer software systems debugging.
]

However, if you've got a good application guy who knows his
stuff, debugging transputer software can be accomplished via
some other method.  However, there ain't no substitute for a
complete software design. :-))

About a reference for occam, the one by Dick Pountain is a great
start.  "A Tutorial Introduction to occam Programming" by D.
Pountain and D. May (the original transputer architect) by
Blackwell Scientific Publications.  Also, a book by Jon Kerridge
"Occam II Programming" also by Blackwell Sci. Pubs.  This is a
little bit more advanced with some useful examples.  Good
reading.


-- 
 Rick 'Transputer' Stein ( My mother was a clairvoyant. :-) )
 uucp:{felix, spsd, zardoz}!dhw68k!stein        
 Internet: stein@dhw68k.cts.com