ccplumb@rose.waterloo.edu (Colin Plumb) (11/09/89)
In article <8911071532.AA28350@tcgould.TN.CORNELL.EDU> K312240@AEARN.BITNET (Klaus Kusche) writes: >Colin will perhaps provide a second edition, but no release date is >fixed up to now - I'll keep you informed. Yes, I'm working on a second edition, with many examples, more details of the obscure instructions, and a reference section so you don't have to hunt through the text to find the order of arguments to enbc, etc. Thanks to Klaus for covering while I, in typical student fashion, bounce around the globe every few months! > If anyone knows about unknown transputer instructions, side effects or > special uses of existing instructions, tricky instruction sequences and > the like, please let us know! Okay, here are two: The "gajw" trick: This trick is very diffiecult to use safely, but I'll describe it along with all the caveats. When you issue a gajw, the processor takes the supplied Wptr, adds the current priority, and uses that as as the new Wdesc. Since bit 1 of the Wdesc is ignored, adding 1 to the Wptr will toggle the process' priority. Note that this is dangerous, since the transputer "knows" that whenever it's running at high priority, there is a process stored in the low memory interrupt locations. Stop the process in high priority, and it will load context from those locations, causing god-knows-what to happen. Also, the trasnputer "knows" that whenever it's running a low-priority process, the high-priority queue is empty. So if any processes get on the queue while in high priority, switching to low will *not* automatically run them. Nevertheless, it can be useful for certain debugging operations and the trick will still work in the T801. The race-condition trick: To find out which of two processes gets to a point first, let them both outword their current Wptr over a common channel. After the outword, look in workspace location 0 (ldl 0). Whichever got there first will have the other process' Wptr there. The second arrival will have its own Wptr there. You can do this with 2n processes on a single channel to pair them up. Have each process allocate a channel and send that as the outword data. Then communicate over that. In also works and has the opposite effect - the second process gets the first process' data. -- -Colin