🚀 go-pugleaf

   While learning assembler, I wondered about how iserver is supposed to be
   used.  If two processes communicate with each other, the length of 
   corresponding 'in's and 'out's has to be same, right?  For the root 
   transputer exchanging data with the host, that doesn't matter, but what 
   for a router process which transports iserver packets between processes,
   e.g. to simulate a virtual transputer network?

   > In OCCAM these messages can be routed as INT16::[]BYTE protocol.

And this means that two seperate communications are performed: one,
transferring 2 bytes (an INT16) designating the length of the following
byte stream. The internal structure of a packet (eg, a PUTBLOCK or what
ever) is irrelevant to the router and is of concern only to the end users.
The aim is to reduce the necessary INs and OUTs and their associated
overhead  it's easier to have the sender pack it all into a byte array
and for the receiver to unpack it. Additionally, it's easy to extend the
protocol (apart from maximum buffer sizes) such that only interested parties
have to take note  a router doesn't and shouldn't care. The only things you
might want to add is addressing and possibly, control over multi/broadcasting.

 Jan Vorbrueggen, jan@Neuroinformatik.ruhrunibochum.de

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

In article <92083073@gandalf.moria>, michael@gandalf.moria (Michael Haardt) writes:
> While learning assembler, I wondered about how iserver is supposed to be
> used.  If two processes communicate with each other, the length of 
> corresponding 'in's and 'out's has to be same, right?  For the root 
> transputer exchanging data with the host, that doesn't matter, but what 
> for a router process which transports iserver packets between processes,
> e.g. to simulate a virtual transputer network?

iserver packets are always send as a 2 byte block containing the length
and a remaining block, containing the packet.  Thanks to Iain Phillips
and Jan Vorbrueggen for answering my questions in detail.

Conor O'Neill additionally suggested to use 'move' to build these packets,
because the components are often misaligned.

I repeat that these block lengths are IMPORTANT, SENDING WITH DIFFERENT
LENGHTS THAN RECEIVING ON THE SAME CHIP IS NOT OK.  It does work between
different transputers, but not on the same chip, at least the
specification says so.

> Do all commercial iserver libraries use the same in/out protocol, which
> is given by the OCCAM data structures?

OCCAM makes a clear definition, so all libraries which would not do so,
would be buggy.

Let me add that I am very glad to see INMOS people being so responsive
in helping users of their products.  It's not the first time that I got
qualified help to my questions from INMOS :-)  My code is rewritten now,
so if its packets ever get to a router, it should work. 

Michael