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