🚀 go-pugleaf

In article <675@prlhp1.prl.philips.co.uk> paszkows@prlhp1.UUCP () writes:
>
>
>    chan.out ! lint1
>    chan.out ! lint2
>
>  
>  SEQ
>    chan.in  ? byte1
>    chan.in  ? int1 
>    chan.in  ? int2 
>    chan.in  ? byte2
>    chan.in  ? int3 
>
>

Having posed the problem, I have managed to solve it myself. Read on for the
solution.

Occam 2 reference manual states that with a PROTOCOL OF ANY, the data sent
is mapped into its constituent bytes, and output as an array.
Input on this channel inputs the array of bytes and converts ( by retyping
conversion ) the value to the type of the receiving variable.

I am not convinced that the last statement holds true ( opinions ? ) as I
had to do the retyping manually.

Anyway, on input channel, read the data into a BYTE array of length equal to
that of the sent data as shown below.

-- retype the bytes into required format.
BYTE byte1 RETYPES inword[5]
BYTE byte1 RETYPES inword[0] :
INT16 inta RETYPES [inword FROM 0 FOR 2 ]
INT16 intb RETYPES [inword FROM 3 FOR 2 ]
INT16 intc RETYPES [inword FROM 6 FOR 2 ]

INT32 int1, int2 :    -- the data being sent.

CHAN OF ANY channel.a :

SEQ
  PAR
    SEQ
      channel.a ! int1
      channel.a ! int2
    SEQ
      channel.a ? [ inword FROM 0 FOR 4 ]  -- receive 4 bytes making up int1
      channel.a ? [ inword FROM 4 FOR 4 ]  -- receive 4 bytes making up int2




   

I'm writing an article about our experiences with Occam I.  I need
a succinct list of the the exact differences in I and II.  Can any
one provide?

Thanks in advance.-- 
Steve Stevenson                            fpst@hubcap.clemson.edu
(aka D. E. Stevenson),                     fpst@prism.clemson.csnet
Department of Computer Science,            comp.parallel
Clemson University, Clemson, SC 29634-1906 (803)656-5880.mabell

Referring to C.P. Winder, ``Parallel Processing with the DisPuter'', in
Developments using occam, Ed. Jon Kerridge, IOS (1988), a paper presented
at the 8th oUG meeting at Sheffield this March, <paszkows@prlhp1> notes that
instruction throughput may be increased by up to 40% by suppressing run-time
range checking. He asks:

> My question is how do you do this? ( For information the software is written
> using Inmos' TDS system ).

The essentials of the program used to obtain these figures are given below:

    --1
    a[i] := b[c[i]]		-- contrived example. []INT a, b, c: INT i:
    a[i] := b[c[i]]
    --2
    a[i] := b[i] + c[i]		-- slightly less contrived example
    a[i] := b[i] + c[i]

Using a T414B-20 on-chip memory with the TDS2-beta release software gave:

	checking on:	69;	77
	checking off:	45;	53

cycles. Smaller speed increases will follow from typical code. It is not
advisable to disable all the error-checking except for highly trusted
sections of code, but other efficiency measures I describe may be more
acceptable. For example, did you know that assignment of a constant to a local
variable in on-chip RAM can take 9 cycles?  (2.2 MIPS for T414-20)

To answer the question, a simple compiler switch can disable run-time checking
on all versions of PC-based TDS that I've seen.

In response to <paszkows@prlhp1>'s follow-up article: beware RETYPEing !  The
compiler will allow you to RETYPE at will but it only works if the word
boundaries are aligned correctly. So,

    [5]BYTE byte :
    INT int RETYPES [byte FROM 1 FOR 4] :

looks OK but doesn't work.

-Phil.
-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
Phil Winder					cpw@uk.ac.oxford.prg
Programming Research Group
Oxford University Computer Laboratory
8-11 Keble Road
Oxford.  OX1 3QD
United Kingdom.