homeis@cs3.ifistg.uucp (03/09/90)
Last Week I found in "asm.h" of Helios a transputer assembler instruction "testhardchan" with two parameters ("chan" in Areg, "val" in Breg): #define testhardchan_(chan,val) _operate(0x2d,chan,val) Helios might use this instruction, or it would not be in the include file. I would like to use it too. By the way, this include file contains another (officially) undocumented instruction, which I know only from the news: #define start_() _operate(0x1ff) This instruction brings the transputer nearly into the same bootable state as after applying a RESET signal, so that the transputer may be booted again from it's links. I don't want to experiment with this undocumented testhardchan instruction. I would be glad, if someone at Inmos would explain, what this instruction does, and what the two parameters mean. (I would prefer an official statement. :-) I have tried to write a fast code to find out, wether a LinkIn has received a message or not, but all constructions with ALT were too slow. In other words, I want to find out the status of the DMA unit. Does the testhardchan instruction do this? Which types of transputers are able to execute this instruction? Does anybody know other undocumented instructions? -------------- Dieter Homeister, Universitaet Stuttgart, Institut fuer parallele und verteilte Hoechstleistungsrechner (IPVR) 7000 Stuttgart 1, Azenbergstr. 12, Tel 0711-121-1342 e-mail homeister@informatik.uni-stuttgart.dbp.de
zenith-steven@CS.YALE.EDU (Steven Ericsson Zenith) (03/13/90)
Ok, this is out of memory, but I'm sure someone will correct me if I'm wrong (Colin Plumb maybe). The purpose of testhardchan is to read internal registers associated with link communications, and is really only useful after assertion of analyse. Internally each channel (two channels per link; one in, one out) has three associated registers: 1) a data register which holds the most recently communicated data 2) a pointer register which points to the source/destination of the data 3) a count register of the bytes in the message It runs like this: A reg = a link address B reg = some value n A' reg = the value of that channels data register B' reg = C reg What happens internally is the data register now contains the value of the pointer register, the pointer register now contains the value of the counter register, and the counter register contains the value n from the B register. Thus by repeated instances of testhardchan, and feeding the data back into this pipeline you can inspect the links internal registers and leave them unchanged. Don't expect this to run, but it would be something like this: [3]INT linkState: seq seq i = 0 FOR 3 seq ldc linkAddress testhardchan linkState[i] := Areg testhardchan The value of the count register (linkState[2]) is the only useful value as I recall. The readiness of an input channel is indicated if the value of the count register is 1 (you have to make sure this was initialised to 0 though). An output channel count register indicates the number of bytes remaining in the message. I haven't run anything to test what I'm saying, so some of the detail may be out, but the general gist of it is here. Regards, Steven. . Steven Ericsson Zenith * email: zenith@cs.yale.edu Department of Computer Science | voice: (203) 432 1278 Yale University 51 Prospect Street New Haven CT 06520 USA. "All can know beauty as beauty only because there is ugliness"
ccplumb@lion.waterloo.edu (Colin Plumb) (03/14/90)
In article <18835@cs.yale.edu> zenith-steven@CS.YALE.EDU (Steven Ericsson Zenith) writes: > Ok, this is out of memory, but I'm sure someone will correct me if I'm > wrong (Colin Plumb maybe). I can but try... but you're right, as far as I can tell. I don't recall the order in which the registers are connected, but there are three registers holding buffered data, a pointer to the current location in the message buffer in memory, and a count of the number of bytes to go on this message. On output channels, this count is always >1. On input channels, it can be -1 if a byte has arrived but no ack has been sent because no local input has been attempted. With four testhardchan instructions, you can read out and restore the complete state of a channel... but if a byte arrives while you're doing it, you're in trouble! It's useful when the network is quiescent to see what was going on, but can't be used on an active channel. I've never found a use for it. At Cogent I was thinking of putting a context save (all the low memory locations, on-chip registers, and whatnot) into the bootup ROM, but I don't think it's ever happened. And, yes, #1ff (pfix 1, pfix f, opr f) is cold boot. Asserting the reset line and executing this instruction are synonomous. (For a *really* obscure feature, opr 9ff; adc 0 clears the timer interruot enable flags - but won't work on the T810.) -- -Colin