home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / transput / 973 < prev    next >
Encoding:
Text File  |  1992-08-31  |  2.6 KB  |  85 lines
  1. Newsgroups: comp.sys.transputer
  2. Path: sparky!uunet!inmos!news
  3. From: conor@lion.inmos.co.uk (Conor O'Neill)
  4. Subject: Re: Usage of in/out concerning iserver packets?
  5. Message-ID: <1992Sep1.083639.20033@inmos.co.uk>
  6. Sender: news@inmos.co.uk (The Usenet News System)
  7. Reply-To: conor@inmos.co.uk (Conor O'Neill)
  8. Organization: INMOS Limited, Bristol, UK.
  9. References: <92083073@gandalf.moria>
  10. Date: Tue, 1 Sep 1992 08:36:39 GMT
  11. Lines: 72
  12.  
  13. In article <92083073@gandalf.moria> u31b3hs@pool.informatik.rwth-aachen.de (Michael Haardt) writes:
  14. >> Every communication, both to and from the server, is a counted array of
  15. >> bytes.  The first two bytes are a (little endian) count of the following
  16. >> message length.
  17. >> 
  18. >> In OCCAM these messages can be routed as INT16::[]BYTE protocol.
  19. >
  20. >An example for a data packet is the PutBlock Function:
  21. >
  22. >> To server:    BYTE           Tag = 24
  23. >>               INT32          StreamId
  24. >>               INT16::[]BYTE  Data
  25. >
  26. >Somehow I don't understand it.  How will the packet be sent?
  27. >
  28. >-   INT16, rest as single BYTEs
  29. >-   INT16, rest as one block of BYTEs (I have no knowledge of OCCAM, sorry)
  30. >-   INT16, BYTE, INT32, INT16, rest as single BYTEs
  31. >-   INT16, BYTE, INT32, INT16, rest as one block of BYTEs
  32.  
  33.  
  34. This will be sent, as mentioned above, as an OCCAM counted array protocol.
  35. On existing transputers, this is implemented by sending a length
  36. (in the format specified by the protocol), and then sending another
  37. single communication which is that many bytes long.
  38. Therefore your second choice is correct.
  39.  
  40. Given the declarations
  41.  
  42.   PROTOCOL SP IS INT16 :: []BYTE :
  43.   CHAN OF SP ts, fs :
  44.   INT16 len :
  45.   [lots]BYTE buffer :
  46.  
  47. pseudo-code for
  48.  
  49.   SEQ
  50.     ...  pack data into 'buffer'
  51.     ts ! len :: buffer
  52.  
  53.     fs ? len :: buffer
  54.     ...  unpack data from 'buffer'
  55.  
  56. would look like:
  57.  
  58.   SEQ
  59.     ...  pack data into 'buffer'
  60.     ts ! len   -- two bytes, since len is an INT16
  61.     IF
  62.       len <> 0
  63.         ts ! [buffer FROM 0 FOR (INT len)] -- 'len' bytes
  64.       TRUE
  65.         SKIP
  66.         
  67.     fs ? len   -- two bytes, since len is an INT16
  68.     IF
  69.       len <> 0
  70.         fs ? [buffer FROM 0 FOR (INT len)] -- 'len' bytes
  71.       TRUE
  72.         SKIP
  73.     ...  unpack data from 'buffer'
  74.  
  75. (However, on the T9000, the variable length i/o instructions will be used).
  76.  
  77. Note too, that the data which is packed into the buffer will often be
  78. mis-aligned, and therefore should be copied into and out of 'buffer'
  79. using a 'move' instruction rather than 'ldnl' and 'stnl' etc.
  80.  
  81. ---
  82. Conor O'Neill, Software Group, INMOS Ltd., UK.
  83. UK: conor@inmos.co.uk        US: conor@inmos.com
  84. "It's state-of-the-art" "But it doesn't work!" "That is the state-of-the-art".
  85.