Newsgroups: comp.sys.transputer
From: andyr@wizzy.com (Andy Rabagliati)
Subject: Re: OCCAM: Best way to multiplex protocols over one link?
Organization: W.Z.I.
Date: Mon, 2 May 1994 17:24:47 GMT
Message-ID: <Cp6r1B.CEC@wizzy.com>

In article <2q2n9b$bg7@mail.fwi.uva.nl>,
Robert Belleman <robbel@fwi.uva.nl> wrote:
>
>My problem is not the avoidance of deadlocks (not in the first place),
>rather how to efficiently relay different channel protocols over one
>link. As an example, consider the following protocol:
>
>    PROTOCOL PACKET
>      CASE
>        file;       INT::[]BYTE           -- note: counted array
>        mats;       INT::[][2][2]REAL32   -- note: counted array
>        box;        [64][64][64]INT16     -- static, BIG array (512k)
>        status;     INT
>        start;      BOOL
>    :
>

>
>I had hoped to get away with a process like this:
>
>    PROC mux([]CHAN OF PACKET from.process, to.process,
>             CHAN OF ANY out, in)
>
>      PAR
>        -- First part: receive packets from processes and send them over
>        -- to the other side;
>        --
>        [BUFSIZE]BYTE buffer:
>        []CHAN OF ANY from.proc RETYPES from.process :
>        WHILE TRUE
>          ALT id=0 FOR (SIZE from.proc) -- for each channel from a process
>            from.proc[id] ? buffer      -- get packet from this process
>              out ! id; buffer          -- send process id and buffer


You cannot do this, or any simple variant of it. It might be possible
in assembler using some of the instructions that make up ALT, in
combination with high priority processes, but I have never thought it
worth my time to try. Maybe that is how the Virtual Channel software
works.

Much greater performance improvements, and better memory utilisation,
come about by not doing all the copies in the first place, and passing
pointers around, in C or occam. See my reply to the "buffer copying
problem" a month ago.

Message-ID: <CnwxGE.2HA@wizzy.com>
Date: Thu, 7 Apr 1994 23:33:49 GMT

>Is the Inmos Virtual Channel Software capable of handling variable
>sized messages efficiently?

I think so. I have not actually used it, myself. I always get picky on
performance, and prefer to tailor the comms to the application, rather
than use general solutions.

Cheers,     Andy.

