🚀 go-pugleaf

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".

In article <9105161505.AA01949@rt.el.utwente.nl> sun@rt.eltn.utwente.nl (Johan Sunter) writes:
>    PROC process.1(CHAN OF ANY to.p2)
>      [100]BYTE buffer:
>      INT s, h1, h2:
>      SEQ
>        REAL32 r RETYPES [buffer FROM 0 FOR 4]:
>        INT    i RETYPES [buffer FROM 4 FOR 4]:
>        BOOL   b RETYPES [buffer FROM 8 FOR 1]:
>        REAL64 x RETYPES [buffer FROM 9 FOR 8]:
                                  ^^^^^^^^^^^^

Note that there is an implementation restriction in current INMOS
compilers that this RETYPES must be word-aligned.
It will be caught by a run-time check.
(Yes, I know that this example should be caught at compile-time).

This is because transputers cannot access non-word-aligned objects efficiently.



---
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".