🚀 go-pugleaf

In article <92083073@gandalf.moria> u31b3hs@pool.informatik.rwth-aachen.de (Michael Haardt) writes:
>> Every communication, both to and from the server, is a counted array of
>> bytes.  The first two bytes are a (little endian) count of the following
>> message length.
>> 
>> In OCCAM these messages can be routed as INT16::[]BYTE protocol.
>
>An example for a data packet is the PutBlock Function:
>
>> To server:    BYTE           Tag = 24
>>               INT32          StreamId
>>               INT16::[]BYTE  Data
>
>Somehow I don't understand it.  How will the packet be sent?
>
>-   INT16, rest as single BYTEs
>-   INT16, rest as one block of BYTEs (I have no knowledge of OCCAM, sorry)
>-   INT16, BYTE, INT32, INT16, rest as single BYTEs
>-   INT16, BYTE, INT32, INT16, rest as one block of BYTEs


This will be sent, as mentioned above, as an OCCAM counted array protocol.
On existing transputers, this is implemented by sending a length
(in the format specified by the protocol), and then sending another
single communication which is that many bytes long.
Therefore your second choice is correct.

Given the declarations

  PROTOCOL SP IS INT16 :: []BYTE :
  CHAN OF SP ts, fs :
  INT16 len :
  [lots]BYTE buffer :

pseudo-code for

  SEQ
    ...  pack data into 'buffer'
    ts ! len :: buffer

    fs ? len :: buffer
    ...  unpack data from 'buffer'

would look like:

  SEQ
    ...  pack data into 'buffer'
    ts ! len   -- two bytes, since len is an INT16
    IF
      len <> 0
        ts ! [buffer FROM 0 FOR (INT len)] -- 'len' bytes
      TRUE
        SKIP
        
    fs ? len   -- two bytes, since len is an INT16
    IF
      len <> 0
        fs ? [buffer FROM 0 FOR (INT len)] -- 'len' bytes
      TRUE
        SKIP
    ...  unpack data from 'buffer'

(However, on the T9000, the variable length i/o instructions will be used).

Note too, that the data which is packed into the buffer will often be
mis-aligned, and therefore should be copied into and out of 'buffer'
using a 'move' instruction rather than 'ldnl' and 'stnl' etc.

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