NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/sys/transput/930

Internet Message Format | 1992-08-14 | 7.8 KB

Path: sparky!uunet!mcsun!uknet!uos-ee!ee.surrey.ac.uk!R.Peel
From: [e-mail] (Roger Peel)
Newsgroups: comp.sys.transputer
Subject: Why should you consider using occam?
Message-ID: <[e-mail]>
Date: 14 Aug 92 15:56:39 GMT
Sender: [e-mail] (Roger Peel)
Organization: University of Surrey, U.K.
Lines: 125


A recent item asked whether anyone still used occam to program
transputers.  My response is a definite YES!  Perhaps I should also retort
by asking why anyone should wish to program these exciting processors in
an insecure sequential language such as C - but I am not that brave.

I have programmed in occam for 7 or 8 years now, and have no plans to
switch.  Apart from personal use, I teach it as a vehicle for parallel
programming, and I supervise many project students (from undergraduate to
research levels) who use occam, typically, to control transputer-based
hardware.  In appropriate circumstances, of course, I also use a number of
other languages.  I suggest that my occam program design experience, in
particular, has made me a better sequential programmer.  Why?

Occam is a small(ish) language with well-defined semantics.  It
incorporates many features not found in other mainstream languages,
especially its built-in timer.  Being a fully-typed language, the compiler
checks that expressions are consistent (like many other modern languages -
but not C).  The need for explicit type conversion is irritating at times,
but is catching on elsewhere because it allows one to reason about how
expressions are evaluated without having to memorise complicated automatic
coercion rules.  Remember that addition and multiplication are not
strictly associative or commutative if their results are only finite-width
binary words.  In occam, functions are guaranteed to have no side-effects,
and therefore (for any set of operands) will ALWAYS return the same
result.

OK - so much for sequential safety features.  But what makes occam unique
is that the concept of proper support for multiple parallel processes and
inter-process communication is built in, and is very easily accessible by
the programmer.  For any task which involves real-time activity, I/O
buffering, interfacing with peripheral devices or just plain parallel
processing, this is really profitable.  It means that we can keep the
separate elements of our task apart - with processes which supervise the
slow peripherals, FIFO buffers to keep them fed, and processes for the
separate computational activities which drive them.  A big fuss is being
made about object-oriented methods these days, but message-passing
parallelism is an even more powerful concept - not only cannot processes
interfere with each other unless invited to communicate, but they can also
run in parallel on appropriate hardware!  All this is achieved by the
strict type-checking of what is communicated along the channels between
processes, as well as stored within.  Hence any message-passing parallel
language without an equivalent of the occam channel PROTOCOLs does not
provide this necessary security.

So why is occam not liked by so many programmers?  Well, some write
sequential code for which occam only provides a few extra benefits.  Fine
- they can justifiably continue to use a sequential language provided they
only attempt to run their code on a single transputer.  Parallel
enhancements to a sequential language might be acceptable for particularly
large-grained parallel tasks, too, but this is not where occam stands out,
either.  Some objectors - rightly - object to occam's lack of standard
facilities such as structures or records (although these will become
available in occam 3).  Others may be worried that they will suffer
withdrawal symptoms if they are unable to use untyped pointers.  A few
maybe even enjoy wasting time wading between breakpoints inside a
debugger, rather than picking up their mis-conceptions and typos in a
compiler.  Instead, I prefer the world of dozens of lightweight parallel
processes, buffers, multiplexers, FIFOs, PROTOCOLs, ALTs and a simple,
clean syntax to describe them.  But I suggest that the majority of
objectors have not been able to re-organise their thought processes
sufficiently to see how to exploit the novel features occam provides, and
in particular they do not see the need for fine-grained parallelism and
data management.  Many are still struggling to manage their real-time task
using polling inside their main program loop, with semaphores, shared
memory buffers and interrupts for added entertainment.

So how should one learn about occam?  My experience is that it only takes
about 4 hours to teach the whole of the occam _syntax_ to competent Pascal
or C programmers, so an evening reading the Occam Reference Manual is a
good start.  However, just this is likely to create the doubters who
voiced the original question.  It is then necessary to spend a couple of
days looking at the applications side of the language - the occam idioms -
with an experienced occamist.  Sequential programming courses have their
sorting, searching, pointer manipulation and data organisation elements,
and one should not expect to understand occam until aspects of buffering,
real-time response, deadlock and so on have been clearly demonstrated.
Many such courses are available, perhaps especially in the U.K.  Even
better, go to a technical meeting or workshop run by NATUG, WoTUG or your
own national transputer user group, and take the opportunity to talk with
the tutors, speakers and delegates about their occam experiences.

And what of the future of occam?   Occam 3 will provide more of the
facilities which are found in the larger sequential languages, but
provided in a secure, type-checked fashion.  More importantly, it will
include a sophisticated scheme for modularising programs, enabling very
large occam programs to be created by teams of programmers in a controlled
fashion.  Think of this as the provision of library modules which can call
the user's program as well as be called by other programs (and remember
that this has to work in a parallel environment) and you will get a feel
for the ideas in the pipeline.  Occam 3 will also have new facilities for
shared channels, which not only maps onto the new fast ALT mechanism
provided by the T9000, but also means that a process can monitor such a
channel without having to know how many processes may send messages along
it, which will make such processes more general-purpose and easier to
design for re-use in a module.

It would be nice to see future occam compilers which generate code to run
on processors other than the transputer.  I would love to be able to
program DSP chips or single-chip microprocessors in occam, rather than in
C or assembler.  In order to facilitate this, WoTUG (with considerable
support from INMOS) will be running an Occam Re-targeting Workshop at the
University of Kent, England, on 15th-16th September 1992.  This will
provide a complete insight into the occam compiler front-end which is
available from INMOS and provides a framework for code generation onto the
processor of your choice.  There will, of course, be the opportunity to
discuss a joint strategy for such re-targeting exercises.

Immediately before the Occam Workshop, on 14th-15th September, WoTUG will
be running a T9000 Systems Workshop in which yet more INMOS staff will be
presenting a comprehensive guide to how best to utilise the new facilities
found on the T9000.

For details of both workshops, contact : Judith Farmer, Computing
Laboratory, University of Kent, CANTERBURY, Kent  CT2 7NF, U.K., or email
[e-mail].


Roger M.A. Peel
Department of Electronic and     Phone : [phone]   (0483 from UK)
      Electrical Engineering       Fax : [phone]
University of Surrey             Telex : 859331
Guildford                        JANET : [e-mail]
Surrey  GU2 5XH                   UUCP : ...mcsun!ukc!ee.surrey.ac.uk!R.Peel
United Kingdom