[comp.sys.transputer] undocumented instruction testhardchan

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