Random occam/occam-pi/CSP related things

[ about | gpuboids | game | amusements | mandelbrot | occwserv | dxraster | xraster | links ]

About occam-pi and CSP

CSP, Hoare's Communicating Sequential Processes, is a process algebra from which the occam language is derived. Having its roots in the mathematically specified semantics of CSP, occam provides a secure (and relatively simple) way to write parallel programs. The occam-pi language is an extension of the occam language that incorporates ideas from Milner's pi-calculus, i.e. those of data, channel and process mobility. Also incorporated are various other features, e.g. dynamic process creation, process priority and extended synchronisations.

The syntax of the occam language tends to put people off a bit, as it insists on compulsary indentation. One of the good things about this is that it makes it harder for people to write ugly code. Steps are being taken to adjust the syntax, in a way that should make it more appealing to C / Java programmers. Anyone whose tried to get threads programming right in Java will probably appreciate the simplicity of parallelism in occam.

GPU Boids

16k boids on the GPU (screenshot)

One of my summer activites this year (2012) was experimenting with occam-pi boids implementations using the GPU and CUDA to speed things up. In summary, successful, but not hard-optimised yet. This is just a dump of the particular files I've been working with and instructions on how to build them.


  1. A working KRoC installation (trunk branch), with the raster graphics stuff in it (for the on-screen display and interaction). Installing the necessary "dev" packages as part of setting up KRoC should provide all this.
  2. A working CUDA install with all the appropriate tools.
  3. And, of course, a CUDA capable GPU! I've been testing this stuff with a GTX-570 and a GTX-590. No OpenCL experiments yet I'm afraid..

And then grab these files (save somewhere useful):

Then with a KRoC environment at the ready, and assuming the bash shell, compile this with:

nvcc -Xcompiler $(kroc --cflags | tr ' ' ',') -arch sm_13 -c boid_cuda15.cu

kroc -v -k --oc-opts="-DEF N.INITIAL.BOIDS=16000 -DEF N.INITIAL.OBST=10 -DEF N.WIDTH=16 -DEF N.HEIGHT=12" \
	occoids-gpusvr15.occ boid_cuda15.o --cc-opts="-lcudart"

Assuming that compiles successfully, you should be left with a binary occoids-gpusvr15 that you can run. The various compiler command-line parameters do have sensible defaults if not set explicitly, but visualisation and interactivity are off by default. If particular limits are exceeded at run-time (e.g. N.MAX.VIEWABLE.AGENTS, the program will bail).

Have fun! :-)

Updated 28/04/2013: I've pulled this into the main KRoC distribution (from version 1.6.0 onwards), such that if you have the cuda tools installed, kroc should build an "ocuda" module that contains this as an example (in "modules/ocuda/examples/"). Also a real-time Mandelbrot fractal thing in there for fun (and it's surprisingly fast with a GTX-570!).

The New occam Adventure

--> [shop1] locn 69
--> The Shop
--> You are standing in a shop.  Assorted goods fill tables
--> and shelves.
--> other people: shopkeeper
--> there is an exit to the south
<-- drop sausage
fred dropped sausage
--> sausage appeared
--> gold appeared
<-- get gold
--> picked up gold
<-- s
--> [village2] locn 66
--> The Village
--> You are in the village.  Regular village activities
--> happen around you.  People bustle around buying and
--> selling goods from rickety-stalls.  You see a well
--> to the south and a shop to the north.  The village
--> extends to the east and west.
--> you are alone
--> there are exits to the north, east, south, west
<-- inv
--> carrying: gold
new adventure game process network

The first version of the occam web-server had a built-in MUD-style adventure game, albeit not a very good one. This turned out better than expected in the end, so I've written a new one (properly this time). The old version was largely static and had a centralised process interface. The new version models the problem much more naturally -- rooms, objects and clients are all individual processes, dynamically reconnecting themselves. I.e., the state held for ``an object in a room'' is not ``some data in a huge array of objects, looked-up by room'', but rather a direct channel connection between the `object' and `room' processes. Similarly, a client moving between rooms is implemented by one room communicating a channel-end (of the client) to another room.

Whilst this new version is much better, imo, is is very non-centralised. This makes, for example, sending a message to all connected clients mildly tricky. The only state currently retained centrally is an array of connections to rooms (used to locate rooms when linking the game together), and an array of logged-in usernames (to stop user-name clashes, although lots of people with the same name works fine).

The default world comprises of some 130+ rooms, and a good handful of bots. The three currently supported client interfaces are the console (keyboard/screen tty), a socket-interface (for regular MUD clients, like TinyFugue), and an IRC-bot based interface that allows IRC users to interact with the game. Note: the IRC interface is disabled by default -- because users interact through the same IRC bot (via private messages), IRC servers tend to think the client is flooding and disconnects it. This can be cured by configuring the IRC server appropriately. Note: largely out of curiosity I wound up the numbers; game still works fine on my P3-800 with 100,000 rooms and 1,000 bots wandering around it :-).

The game is built and re-arranged using a mixture of compiled-in code (in `game.occ'), script commands (read out of a file), and user-entered commands. There's not an awful lot of them at the moment, however. The initial tty client can use various commands not available to telnet client. Use `help' or `?' to get a list of commands.

There are various object and bot types in the game, defined in `game-objects.occ' and `game-bots.occ' respectively. These could be better, etc. ;-). At some point I'll probably re-do the client interface code, it's a bit messy at the moment. Update: that's been tidied up now, but it's not exactly trivial.

Download (and edit the `config.inc' file):

Release notes:

  • version 0.3: quite a lot of changes. This version compiles with KRoC/Linux 1.3.3 (final). Socket deadlocks, etc. all fixed, and general updates; more bots, more rooms, more objects, ... Users now have `health' and `vitality', and may attack each other with various objects. The knife, sword and candlestick are pretty effective. Health-replenishing objects (bread, ribena and cookies) randomly appear around the game -- the `cleaner-bots' will randomly sweep these things up (avoids rooms getting over-full ;)). Note: wizards and some other special bots don't like being attacked ;).
  • version 0.2: not a huge amount has changed, but this version is now working properly with KRoC/Linux 1.3.3-pre26. Client interface code still needs sorting out (logout via the socket interface deadlocks)
map of the game

Future plans for this are to tidy up the IRC-bot interface and add the occam web-server client interfaces. Also, there is no support for directed object/person or object/object interactions. I.e., you can't give an object to someone, or say something to just one person. Support for such things is easily added, however -- more PROTOCOL cases and code to handle them.

Currently, a `player' interacts with other game objects either by using them directly (gateways and photocopiers, for example), and interacts with the game `bots' by dropping objects in the same room as them. For example, there's a trader-bot roaming around -- drop an object in the same room as him and he'll drop some silver in return. There's only one trader at the moment; because he'll exchange silver for silver, two traders in the same room might get livelocked ;-) -- until a player steals the silver before the other trader sees it, of course.. Drop silver in the same room as gandalf and he'll open a gateway to another part of the game.


          ||              %-P     12
          || %-[                  10
          ||                %-]   12
     =:-] ||       %-]            12
          ||       %-P            9
          ||                 %-]  10
          || %-[                  9
          ||                 %-]  9
          ||               %-P    8
          || %-[                  8
          || :-(                  3
          || :-(                  1
          || :-(                  1
          || :-(                  0
          || :-(                  0
          || :-(                  0
          || :-(                  0
          || :-(                  1
          || :-(                  0
          || :-(                  0

keys: 0 = normal alt,  1 = fairer alt,  2 = fair alt
bar.occ - a simulation of people buying beer at a bar, demonstrating various forms of ALTing. Pressing the `0', `1' and `2' keys while the program runs will change the behaviour of the ALT. It effectively demonstrates starvation when using a non-fair ALT, as the bods at the top have already collapsed before the bods at the bottom get served! When turned to the fairer-ALTs, all get served equally.
Here's a picture of the simulation mid-execution. The bod on the left is the bar-keeper, and the others run to and from the bar drinking beer. The number on the right indicates how many pints they've had. After 15 pints, they will collapse.
  • Some mod/fixes, Oct 2001, by Peter Welch (renamed to bar.occ)
better-bar screenshot
bb.occ (162.4k) is a newer, shinier version of the bar above. The instructions are presented in-game, but it's mostly sit-back-and-watch stuff. The game is a sort of paintball philosophers, where each player drives a buggy around the arena, shoting philosophers. You die if you don't hit anything for 9 seconds. Hitting the same philosopher multiple times while they're waiting somewhere is permitted, but not very sporting ;-).
This isn't all completely here yet, but mostly so. The things I need/want to finish/add are:
  • make the pool-table work
  • there is an ambulance process on the way, but the philosophers need to get injured somehow first (hit '#' to see it)
  • code to walk them around still requires a bit of tweaking
As per usual, this is released under the terms and conditions of the GNU General Public License. In order to compile it, you will need at least KRoC/Linux 1.3.2. My preferred command for compiling this is:
    kroc bb.occ
| Noddy:     |      |                                |      | Deforest:  |
|            |      |                                |      |            |
[unch...     ]                                              [m yum... Mun]
|            |      |                                |      |            |
+------------+------+               :)               +------+------------+
| Euclid:    |      |              ----              |      | Vladimir:  |
|            |   z  |            / Spag \            |      |            |
[     Sleepin]  |)               \ Bowl /                   [ope, I am hu]
|            |      |              ----:O            |      |            |
+------------+------+                                +------+------------+
|                   |                                |      | Einstein:  |
|                   |                                |      |            |
|                   |                                   :)  [ng about for]
|                   |      +------------------+      |      |           / 
|                   |      |  Security (2/4)  |      +------+---------+   
|                   |      +------------------+      |     Think Tank |   
|       :)          |                 :O    ||       |                |   
|   philosophers die in their sleep.         |   o O              O   |   
|                                            |           O            |   
| Information:                               |      o                /    
philfred.tce.gz (12k) - a simulation of the dining philosophers. This is an ETC (compiled occam) file. If you want the sources to this then mail me.
To turn this into an executable file, run the following commands:
$ tranx86 -kf -o philfred.o philfred.tce
$ kroc philfred.o -lcourse
(this only works on KRoC/Linux 1.3.0 and above).
Note: this animation is now part of the KRoC/Linux source release, as `course/answers/q7-fred'.
[       J } }       S   S         2   v   , F I     g f         v 5   5   q   e
z       & K ?       U   C         &   }   ! / b     z 8         ' 2   [   p   r
v 2     R * F       Y   ;         Z   e   x g q     ; 5         E /       $   B
w "     1 ? I     U H   !         z   d 5 < y Z     \ [         / %       '   ^
8 #     o )       P     _         k   U p E ;       B G H       4 =       @   ~
> Z     - h   4   t     k             : q C '         C R   S   &       5 I   O
' H     I u   )   +           E       a &         i   6 i   j   O       4 E   w
< N     b b   N   (   <       .       q a         1   N _   1       5   K X x )
2 2     a C   m   X   N     z ~     % e U       N 0   3 N   t       /   m   0 j
_ 1     3 &   # \ b   (   h 9 f ^   ` @ C       d ;   n 9   h       o   `   A d
  0 -   > :   f o p   /   3 K J C   O g h       5 O   [ \   m c     |   9   Z [
  J M     U   ` 9 f   @   f ? @ p   Z # T       > Q     i   a q     P   Y   e  
    ~     2   > F D   M   . c B W   M   j       1 8     L   > j     > 9 |   k  
    3 4       j I x   J   h r N a   /   I     < [ y     <   Y _     # s X   #  
    T p     { D j 5   l   v { q 3   l   h     4 p ;     * %   Q     % / z   )  
    $ W     . H x     ^   s ; C !   0   t L   v i 7       L   l     N N s   m  
    B '     3 r `   d f X * 9   h   A   V i : c = Y       1   I     V 0 `   H  
    w a     h v z   D Y I B }   N       t 9 ? T B p       K   8     j | a   9  
      P     d ' n   r 8 - h s   k         6 N y ]   M     \   D     } 5 > R A  
      0     R   m   t O " A       ^       ? ; C k   !     ]   ;     - y   t    
      M d   x   }   E r T !       c   >   9 C K ]   b     B         G n   U    
      } {   ,       ^   K         +   (   ' Z ( l   w     <       " , g   m    
        B   T       .   ,         7   I   x R t     0     %       )   y   .    
        * ! w       [   }         B   C   ( D v     ( !         M x   W   {    
matrix.occ (9.9k) - the usual `matrix-style' animation.
To compile this (requires at least KRoC/Linux-1.3.3-pre8):
    bash$ kroc matrix.occ -lcourse -lconvert -lhostio
And to run:
    bash$ export LINES COLUMNS
    bash$ ./matrix
The `lines' and `columns' environment vars are generally set by the shell, but not exported by default. The animation uses these environment vars (accessed through the hostio library) to work out how many processes to create, and how much each process should draw. For versions of KRoC/Linux prior to 1.3.3-pre25, you will also need the `-X5' flag (to enable the extended rendezvous that the program uses).

Mandelbrot Fractal in occam

Here's a nice example of occam generating a mandelbrot fractal. Acknowledgement to Jim Moores who wrote the documentation from which I extracted the code (it's an example for user-defined operators in occam). The source to generate the text version below can be found here (2k). A modified version generated some nice images which are shown below The program output is bigger than what's below, but I didn't fancy creating massive .html files.

,,,,,,,::::::::::::::::::::::::::;;;;;;;;;||||[$%.:# , [;;;;;;;:::::::,,,
,,,,::::::::::::::::::::::::::;;;;;;;;;;;||||[$$% :[ %$[||;;;;;;;::::::::
,,:::::::::::::::::::::::::;;;;;;;;;;;;||||[[%:..% [[ #%[||||;;;;;;::::::
:::::::::::::::::::::::::;;;;;;;;;;;||||[[[$% $.       %$[||||||;;;;:::::
:::::::::::::::::::::::;;;;;;;;;;|||[[[[[$$%%.,       ;#%$$[[[||||;;;;:::
::::::::::::::::::::;;;;;;;;;||||[,##: %%#   ,;,     .:. #.%$$[$$##[;;;::
::::::::::::::::::;;;;;;;||||||[[$#|,# ,,;|             $  $ #$, ,.#||;;:
:::::::::::::::;;;;;|||||||||[[[$%#.,                       #[  :%:.[||;;
::::::::::::;;;||||||||||||[[[[$#[,:%,                           $#$[||;;
:::::::;;;;|[#$[[[[[||[[[[[[$$%#[[ |                            ;%#%$[|;;
:;;;;;;;|||[[%;%%$$$%:%%$$$$%%%..,                               $$[%%||;
;;;;;;||||[[$%.|#%,..| .|.###  |;                                  ;.$[|;
;;;;||||||[$$%#:;  :    |,;:.,:#                                   ,:[||;
;;||||||[$$$%|: [            |$                                    ,%[||;
||[[[[$$%:. .,#               [                                   $ [|||;
[[[$$$$##,$. .;               .                                  %%$[|||;
[[[$$$$##,$. .;               .                                  %%$[|||;
||[[[[$$%:. .,#               [                                   $ [|||;
;;||||||[$$$%|: [            |$                                    ,%[||;
;;;;||||||[$$%#:;  :    |,;:.,:#                                   ,:[||;
;;;;;;||||[[$%.|#%,..| .|.###  |;                                  ;.$[|;
:;;;;;;;|||[[%;%%$$$%:%%$$$$%%%..,                               $$[%%||;
:::::::;;;;|[#$[[[[[||[[[[[[$$%#[[ |                            ;%#%$[|;;
::::::::::::;;;||||||||||||[[[[$#[,:%,                           $#$[||;;
:::::::::::::::;;;;;|||||||||[[[$%#.,                       #[  :%:.[||;;
::::::::::::::::::;;;;;;;||||||[[$#|,# ,,;|             $  $ #$, ,.#||;;:
::::::::::::::::::::;;;;;;;;;||||[,##: %%#   ,;,     .:. #.%$$[$$##[;;;::
:::::::::::::::::::::::;;;;;;;;;;|||[[[[[$$%%.,       ;#%$$[[[||||;;;;:::
:::::::::::::::::::::::::;;;;;;;;;;;||||[[[$% $.       %$[||||||;;;;:::::
,,:::::::::::::::::::::::::;;;;;;;;;;;;||||[[%:..% [[ #%[||||;;;;;;::::::
,,,,::::::::::::::::::::::::::;;;;;;;;;;;||||[$$% :[ %$[||;;;;;;;::::::::
,,,,,,,::::::::::::::::::::::::::;;;;;;;;;||||[$%.:# , [;;;;;;;:::::::,,,

mandelbrot 1

mandelbrot 2

An occam web-server

occwserv is the occam web-server. Visit http://wotug.kent.ac.uk/ocweb/ to see the server in action. Recent additions include OGIs, which are like CGIs, but consist of pre-compiled occam PROCs which are dynamically loaded into the web-server process network. A few sample ones are included (persistent finger OGI, one-shot and persistent test OGIs, the adventure OGI and a crash OGI (which really will crash the whole lot at the moment!)).

Updated: (10/02/2002) added a new version of the web-server (OGI mostly, plus a prioritised version for priority-enabled KRoCs). The occam adventure now has a pile of ``bots'' which just wander around aimlessly uttering and doing things. Also implemented the help. Added a heap load more stuff to the adventure, plus fixed some bugs here and there. Requires at least 1.3.2-pre3 to build this one, although that version may never be released, I'll see how far away 1.3.2 is, check the kroc page for releases.

Updated: (02/01/2004) version 2 of the occam web-server is nearly ready for release, just a few more tidies and tweaks. This version should be running live on the above (ocweb) URL.

The web-server listens on port 8080 (HTTP) by default, and expects its pages to be in /usr/local/occweb/. These things can be changed by editing the constants defined at the start of "occwserv.occ" and the "ogi/buildme" script (which copies the OGIs (shared objects) into the occweb/ogi directory). I've started munging together an OGI HOWTO to assist in writing OGIs (you'd need to know occam first however..).


See the text below for X-Raster for a description (roughly). This is a better version which uses user-defined channels to interface with the C world. Still will only work on 24/32-bit graphics displays. Here's a piccy of dxstar running with 8 buffers -- looks better when animated :).

dxstar (8 buffers)


This is a fairly simple demonstration of connecting occam to the X Window System (X11). It uses the MIT-SHM extension for quick graphics updates and mobile occam types for manipulation speed in occam. On my P3-800, it consumes around 65 % CPU during the fractal zoom, and less than 1 % CPU thereafter. It displays some static fading text, a scrolly, a vertical-bar thing, and for a while initially, a mandelbrot fractal zoom.

There's also a shadebob thing included (not that it looks much like a shadebob mind), and a "starfall" thing. The shadebob program is a simple set of 4 shadebob type processes which pass the raster between themselves. The starfall program has 6 stars following elpitical tracks at 6 different sizes (to give some sort of 3D impression). At various points round the track (every other point actually), a little coloured star falls off it, which fades as it travels to the bottom of the screen. The rate of fall is controlled by how much in the foreground the star is (related to y). It looks very cool and uses about 7.7% CPU on my P3 800. Worth downloading if you need to look at something soothing for a bit.. In terms of occam processes, there are a bunch of basic things, 6 "starloop" processes and a farm of 512 "starfall" processes. This makes for a pretty good demonstration of ease of parallel programming in occam (only took me about 8 hours from start to finish).

To compile these sources, you'll need kroc-1.3.0 or later. The binaries should run on most Linux distributions. You'll need X11 with a 24 or 32-bit display and MIT-SHM support. The current (fixed) window size is 320x200.

xraster testprog xraster shadebob xraster starfall

Note: if you just want to run the above binaries (without having to install anything), you'll need to create a file called ".kroc_clock" in your home directory, containing the CPU speed in MHz (look at /proc/cpuinfo). You can also (as root) put this information in "/etc/kroc_clock".

Links to other occam related things

Last modified: 2013-04-28 11:18:11.000000000 +0100 by Fred Barnes.