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"