Article View: comp.sys.transputer
Article #1683Re: Anarchic protocol ANY (occam2)
From: Conor O'Neill
Date: Tue, 21 May 1991 12:46
Date: Tue, 21 May 1991 12:46
81 lines
2737 bytes
2737 bytes
The "best" solution is probably to use a combination of counted-array
protocol, run-time assembled tables (I can't think of a better name),
and judicious use of RETYPEs where necessary.
(Yes - work is progressing (slowly) to add records).
I keep wanting to remove CHAN OF ANY from the compiler (:-)
Suppose we want to send a variable number of INTs down a channel;
we can use the following:
PROTOCOL message IS INT :: []INT :
PROC process.1(CHAN OF message to.p2)
INT x, y, z :
SEQ
... initialise the variables
to.p2 ! 3 :: [x, y, z]
:
Then the buffer process can be written as follows:
VAL max.message.size IS 100 : -- your choice here!
PROC buffer(CHAN OF message in, out)
[max.message.size]INT buf :
INT len :
WHILE TRUE
SEQ
in ? len :: buffer
out ! len :: buffer
:
Unfortunately the `unpacking' process at the other end can't use
"run-time dis-assembled tables"! You have to un-pack the items yourself:
PROC process.2(CHAN OF message from.p1)
INT x, y, z :
SEQ
[3]INT buf : -- we know we're expecting 3 items
INT len :
SEQ
from.p1 ? len :: buf
ASSERT(len = 3) -- check that we got what we're expecting
x, y, z := buf[0], buf[1], buf[2]
... and use x, y, and z here
:
Obviously, if you want to communicate values of different types,
you might have to use RETYPES to assemble them into a buffer.
Alternatively, suppose we want to communicate a collection of
BYTEs and INTs:
PROTOCOL message IS INT :: []BYTE ; INT :: []INT :
then send like this:
to.p2 ! 5::[b1, b2, b3, b4, b5] ; 3::[x, y, z]
You may find that this is actually faster than sending eight
items individually.
Note that ASSERT(VAL BOOL test) is a predefine which has been added
to the D7205 occam compiler; it performs a compile-time test if possible,
otherwise it performs a run-time test.
It is basically equivalent to:
PROC ASSERT(VAL BOOL test)
IF
test
SKIP
TRUE
STOP
:
---
Conor O'Neill, Software Group, INMOS Ltd., UK.
UK: conor@inmos.co.uk US: conor@inmos.com
"It's state-of-the-art" "But it doesn't work!" "That is the state-of-the-art".
Technical Details
Message-ID:
<16168@ganymede.inmos.co.uk>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!uunet!mcsun!ukc!inmos!conor@lion.inmos.co.ukReferences:
<9105161505.AA01949@rt.el.utwente.nl>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!uunet!mcsun!ukc!inmos!conor@lion.inmos.co.uk From: conor@lion.inmos.co.uk (Conor O'Neill) Newsgroups: comp.sys.transputer Subject: Re: Anarchic protocol ANY (occam2) Message-ID: <16168@ganymede.inmos.co.uk> Date: 21 May 91 12:46:04 GMT Article-I.D.: ganymede.16168 References: <9105161505.AA01949@rt.el.utwente.nl> Sender: news@inmos.co.uk Reply-To: conor@inmos.co.uk (Conor O'Neill) Organization: INMOS Limited, Bristol, UK. Lines: 81