[comp.sys.transputer] Semantics of In and Out instructions for memory channels?

mccabe@unc.cs.unc.edu (Dan McCabe) (02/26/90)

Does anyone out in Netland know details about the semantics of the In and Out
instructions when a memory channel is specified?  I have examined the
transputer compiler writers' guide (tcwg), but unfortunately it is rather vague
on this matter.  Also the article by Nicoud and Tyrrell in the 6/89 issue
of IEEE Micro provides no details about these instructions (although
they do provide some details of the alt and par instructions on which tcwg
is equally vague).

I know that a channel is initialized with NotProcess.p (-1).  I presume
that a process descriptor is kept in the channel variable.  Is the
channel a linked list of waiting processes?  It seems to me that this would
have to be the case, since several processes may Out to the same channel before
another process does an In.  Are the registers saved in the workspace if
the instruction blocks (when Out executes and there is no pending In or
vice versa)?  If you treat the list of processes as a queue, you also need
a tail ptr for efficient insertion (as is the case for general process
scheduling).  Is there some encoding that says that the channel is waiting
either for an In instruction or for and Out instruction?

Would anyone care to discuss some of these details, either publicly via news
or privately via mail?  If you have pointers to additional references, those
would also be appreciated.

Thanx in advance,
danm

aek@research2.computer-science.manchester.ac.uk (Alan Knowles) (02/26/90)

Dan McCabe asks:

>       Does anyone out in Netland know details about the semantics of the
>       In and Out instructions when a memory channel is specified?
>       .......
>       Is the channel a linked list of waiting processes?  It seems to me
>       that this would have to be the case, since several processes may
>       Out to the same channel before another process does an In.
WRONG.  Only one pair of processes may access a channel: one sending and one
receiving. The workspace pointer of the first process to "arrive" is put in
the channel word and message transfer takes place on the "arrival" of the
second process. It is assumed that rigourous checking has taken place. The
direction and size of message transfer is performed according to the implied
direction of the second "arrival". Only the workspace pointer of the first
"arrival is kept".

Alan Knowles

ccplumb@lion.waterloo.edu (Colin Plumb) (02/27/90)

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