Occam introduction

AN INTRODUCTION TO THE OCCAM TRANSPUTER LANGUAGE
by Micha Claessen

The  aim  of  this  article  is  to  introduce  you to concurrent 
programming  using OCCAM. I will show you some examples of  Occam
programming but I won't discuss the syntax of it (therefore  I'll 
refer  you  to  some other literature).  With the introduction of 
transputer  systems  a new programming language appeared....OCCAM 
(II).  What  is  so  special  about  this  programming  language?
Occam is rapidly being recognised as a solution to the problem of 
programming concurrent systems of all kinds and with  the  coming 
of  transputer  systems it is very simple to imply such language.
The  hardware  allows  and  supports such CONCURRENT programming.
Therefore  the  OCCAM  programming  language  can  be seen as the
'assembly  language  of the transputer'  This  intimate  relation 
between  the  software  and  hardware  will  make  machine   code 
programming  nearly  unnecessary. Of course there always  will be 
some  application  that needs to be programmed in  machine  code.
An  example that shows the power of this programming language  in 
combination with a transputer system: During the SYSTEMS (october 
1987) INMOS showed a flightsimulator based on 11 transputers.
this flightsimulator allows real-time animation of 2  independent 
jets  on 2 monitors (the animation was absolute  perfect!).  this 
project  was developed in only 2 men-weeks.  This  shows  another 
advantage  of the OCCAM programming  language:  solving  parallel 
programming concepts in a very short time! 

CONCURRENT PROGRAMMING

Events  happen  in both time and space.  It is possible  for  two 
events to occur in the same place one after the other in time       
(sequentially),  and  it is also possible for events to occur  in 
different places at the same time (concurrently or in parallel).
If  you  compare  the concurrent nature of  the  world,  and  the 
sequential  nature  of  the computer there would  seem  to  be  a 
serious  mistake!  (since the main purpose of the computer is  to 
model the world (e.g.arcade games,animations,process simulations)
To adequately model the concurrency of the real world,  it  would 
be  preferable  to have many processors all working at  the  same 
time on the same program.  Conventional programming languages are 
not  well  equipped  to  construct programs  for  such   multiple 
processors as their very design assumes the sequential  execution 
of  instructions. Take a game like GOLDRUNNER,  when you run  the 
program it seems to work parallel!  You listen to nice music  all 
the  time,  and  the  fast scrolling,  the  main  ship,  all  the 
attacking  sprites  seem  to move at  the  same  time!  Even  the 
reaction on moving the joystick seems to happen in 'real time'!!!
In essence what happens is that the programmer (Steve Bak) writes 
a number of routines and the computer pretends to run them all at 
the same time by running a piece of each one in turn, swapping at 
very  short  intervals.  If you program this game in OCCAM  on  a 
transputer system containing different transputers,  you are able 
to  let  the  different transputers take  care  of  your  program       
(1 transputer takes care of a stunning piece of digitized  music, 
the other handles the ultra fast 'n soft scrolling,  one for  the 
fast  and colorful sprites,  maybe you let one transputer  handle 
the rasterinterrupt for getting some real nice  coloreffects....)
An other real nice application working in parallel is RAY-TRACING
This  technique is used for creating very realistic  3D  pictures 
where  every  point on the screen is calculated  by  tracing  the 
light-beam backwards.  Conventional computers can only do this in 
sequence ( like GFA-RAYTRACE), but on transputer systems this can 
be  done  real fast spreading the calculations over all the  used 
transputers.  (And when you imagine the possibility of using  the 
amount of colors on the ABAQ.....).

SYNCHRONISATION

However.............. parallel programming is more difficult than 
straightforward sequential programming (do this, then do this...) 
This  is because a sequential program has only one beginning  and 
one  end,  but a concurrent program may have many beginnings  and 
many ends. Let's take an example of a program....         

      seq
          scroll the backplane
          move the sprites
          adjust the hiscore
          scan the joystick
          (re)calculate the coordinates of the sprites
          throw some parameters to the soundchip 

where the SEQ means "do all these in sequence".

You  can't play the game correctly without any of this sequences.     
the  most  efficient  way  to  proceed is let run these sequences  
parallel.  But since you can't miss any of this sequences  you'll 
have to wait until everything is done.  Unless all activities can 
be suitably synchronised the result is a big mess!
So if cooperating programs don't finish their parts of the job at 
the  right  times,  or a program is perfectly  prepared  to  wait 
forever  for  something  which  will  never  arrive  because  the 
synchronisation  is wrong ( a situation known as a DEADLOCK)  the 
result is usually not quite nice.

Occam  simplifies  the writing of concurrent programs  by  taking 
most  of the burden of synchronisation away from the  programmer. 
For instance, our game could be described by:

       seq 
         par
            scroll the backplane
            move the sprites
            adjust the hiscore
            scan the joystick
            (re)calculate the coordinates of the sprites 
            throw some parameters to the soundchip (each VBL)
         go_on

Communication  between the different parts of a program is  built 
into the language itself,  and it is synchronized  communication- 
that is, a message will only be sent when both the sender and the 
receiver are ready.

PROCESSES AND CHANNELS

In  Occam  programming  we refer to the parts  of  a  program  as 
processes.

Key idea: A process starts, performs a number of actions and then 
finishes.

This sounds like an ordinary sequential program but in Occam more 
than one process may be executing at the same time, and processes 
can send messages to one other.
Occam  permits this sort of communication as a normal feature  of 
programming,  and doesn't require special instructions which have 
to be different for each kind of communications device.
More  importantly,  Occam doesn't mind whether the  two  programs 
which so communicate are running on different computers,  or  are 
just two processes running concurrently on the same computer.
A channel is a one-way,  point-to-point link from one process  to 
one  other process.

Communication  over  self-synchronising channels is a  novel  and 
powerful  part  of  Occam,  and  it can  render  the  writing  of 
concurrent  programs a far less formidable task than it  is  with 
conventional languages. 

I  hope  this article gives you a view of the  Occam  programming 
language.
If you're more interested in this language or even want to  learn 
it, I can refer you to some very interesting literature.
(I hereby want to thank Techmation electronics b.v.  for  sending 
me some information about transputers and Occam programming)

* A tutorial introduction to Occam programming
* Occam programming
�