Path: utzoo!utgpu!watserv1!watdragon!lion!ccplumb
From: ccplumb@lion.waterloo.edu (Colin Plumb)
Newsgroups: comp.sys.transputer
Subject: Re: Semantics of In and Out instructions for memory channels?
Message-ID: <21317@watdragon.waterloo.edu>
Date: 27 Feb 90 01:12:54 GMT
References: <12243@thorin.cs.unc.edu>
Sender: daemon@watdragon.waterloo.edu
Reply-To: ccplumb@lion.waterloo.edu (Colin Plumb)
Organization: U. of Waterloo, Ontario
Lines: 44

In article <12243@thorin.cs.unc.edu> mccabe@unc.cs.unc.edu (Dan McCabe) writes:
>Does anyone out in Netland know details about the semantics of the In and Out
>instructions when a memory channel is specified?

Only two processes may access the channel at a time.  Any more is an error
which will not be detected by the transputer.  One must be doing an in
and the other an out.  Again, the transputer will silently screw up
if you get this wrong.  They must agree on the message length.  Again,
silent screwup if this is violated.

I don't have my microcode listings with me, so I can't tell you if
the channel word is cleared before or after the block copy of the
message is executed, although I think it's before.  I also forget
at which priority a copy between high and low priority proocesses
is done, although I think it's the second process to become ready.

The implementation is very simple:
A channel word starts out as NotProcess.p (0x80000000).

When a proocess comes along to do an in or an out, it notices that the
channel is empty.  The process stores a pointer to its message buffer
in workspace location -3, its Iptr in workspace location -1, and
its own Wdesc in the channel word.  (Not necessarily in that order.)
Then it gives up the processor.  Note that it does *>>NOT<<* store
the directioon of the message (in or out) or the length.

When the second process comes along, it notices that the channel is not
empty.  It follows the Wdesc to the buffer pointer, copies the message
using its idea of length and direction, wakes up the other process,
and clears the channel word.  Again, not necessarily in that exact order.
The second process continues running.

Note that you can do some tricks with this.  If two processes each put
their Wptr's in a message and try to out it through a common channel,
the process which gets there first will have its pid overwritten with the
other.  You can pair up any even number of processes this way on one
channel, as long as they're all the same priority.

The ALT instructions add more complexity to this, by storing a magic value
in the buffer pointer field which the out instruction recognises and
does some magic about, but I'll leave that unless you really want to
know.
-- 
	-Colin