clare@tesun2.UUCP (Peter Clare) (03/20/90)
Further to the recent discussion on undocumented transputer instructions,
here are some more instructions that I am aware of (in addition to the
"testhardchan" instruction mentioned previously). I know little more
about these instructions other than their operation codes and their
mnemonics:
Operation code (hex) Mnemonic
-------------------- --------
23 testlds
24 testlde
25 testldd
26 teststs
27 testste
28 teststd
2D testhardchan
80 fpsttest
85 fpldtest
A7 fpentry3
A9 fpentry2
>From the mnemonics, one can guess at what some of these instructions might
do. In particular, the two extra fpentry instructions look interesting.
If they work like the normal fpentry instruction then they could lead to
a whole load of extra floating point instructions. If you are familiar
with the transputer instruction set then you will see that these extra
instructions fill in some of the "gaps" between the documented instructions.
Here are some questions. Can anyone on the transputer grapevine provide
any answers?
1) Are there any more undocumented instructions?
2) What do these instructions do? How do they affect registers and
what are the cycle times?
3) Are any of these instructions of any real use other than for testing
purposes?
4) Which instructions are supported on which types of transputer?
===============================================================================
Peter Clare
THORN EMI Central Research Laboratories
Dawley Road
Hayes
Middlesex
UB3 1HH
Tel: 01-848-6521
Fax: 01-848-6565
Eurokom: Peter Clare THORN EMI
email: clare@thorn-emi-crl.co.uk
===============================================================================zenith-steven@cs.yale.edu (Steven Ericsson Zenith) (03/21/90)
In article <9003201450.AA01756@flay.thorn-emi-crl.co.uk>, clare@tesun2.UUCP (Peter Clare) writes: I know little more about these instructions other than their operation codes and their mnemonics: Operation code (hex) Mnemonic -------------------- -------- 23 testlds 24 testlde 25 testldd 26 teststs 27 testste 28 teststd ... 2) What do these instructions do? How do they affect registers and what are the cycle times? You mean the load and store Status Register, E Register and D Register? Nah ... you don't want to know :-) (tease!). Maybe you should ask an INMOS FAE... maybe he doesn't know. Maybe you should read my book when it comes out (how to put the fear of god in INMOS :-) Nah! just kidding guys ... honest!) -- . . 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"
malc@bilbo.inmos.co.uk (Malcolm Boffey) (03/27/90)
This is in response to queries about undocumented instructions for loading and storing the D, E, S registers. In addition to the published registers :- A, B, C, I, W, queue pointers etc, there are a few (D, E) that are used to hold intermediate values in some of the instructions. As they are not saved during interrupts, there seems little use for them in low priority, and they can only be used safely at high priority if you know what instructions are able to corrupt them (which I don't). Anyway, it is easier to use another local variable. The status register (S) holds miscellaneous bits of state like the Error flag and the HaltOnError flag, for which there are already enough instructions to access and alter them. There are one or two other instructions that are used for testing, none of them terribly usefull or interesting. Also, it is more or less a certainty that they will be discontinued in future transputers, or at least change their function significantly. malc. Malcolm Boffey, Transputer Group, Inmos. | Inmos Ltd, UK: malc@inmos.co.uk | 1000 Aztec West, Almondsbury, US: malc@inmos.com | Brisol BS12 4SQ. UUCP: ...uunet!mcsun!ukc!inmos!malc | Tel. +44 454 616616 x522
nick@lfcs.ed.ac.uk (Nick Rothwell) (03/29/90)
In article <4918@ganymede.inmos.co.uk>, malc@bilbo (Malcolm Boffey) writes: >This is in response to queries about undocumented instructions for loading and >storing the D, E, S registers. > >In addition to the published registers :- A, B, C, I, W, queue pointers etc, >there are a few (D, E) that are used ... > There are one or two other instructions that are used for testing, none >of them terribly usefull or interesting. Also, it is more or less a certainty >that they will be discontinued in future transputers, or at least change their >function significantly. > Malcolm Boffey, Transputer Group, Inmos. | Inmos Ltd, This is fascinating. Over in comp.sys.mac there is continual screaming and shouting and wailing and gnashing of teeth over numerous violations of the interface guidelines. For example, some of the good ol' MicroSoft products only work if you run them first (they use the top 8 bits of the address space for tags), there are programs which only drive particular versions of some of the printers, there are drawing programs which reference screen memory directly (and hence break on the newer machines), and so on. Despite Apple documenting the programming interface for the Mac, and giving (admittedly pricey) developer technical support, and not documenting anything lower down, hackers still turn out *commercial products* like this. So, I'm surprised that someone from Inmos will quite happily chat away about undocumented features of the Transputer. Be warned, some programmers will happily use this stuff, and as the new transputers go out into the world, many many pieces of software will go "kablowie" and fall flat on the ground in perfect unison. I hope Inmos doesn't end up with the blame (perhaps their role as hardware vendor makes this a different situation). Me, I'm still irritated that I asked Inmos for the (proper) transputer instruction set back around 1985 and they said "No; go and program in OCCAM." Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcsun!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ i l l C l o u s e a u kill clouseau K I L L C L
malc@bilbo.inmos.co.uk (Malcolm Boffey) (04/06/90)
In article <3159@castle.ed.ac.uk> nick@lfcs.ed.ac.uk (Nick Rothwell) writes: >In article <2076@ifi.informatik.uni-stuttgart.de>, homeis@cs3 writes: >>Inmos should give away more information about the instruction set, and this >>should be done officially. > >Sure, or else state that some of the side-effects manifested by >current hardware in some circumstances is, er, "officially >undefined" and subject to change. > >>Dieter Homeister, Universitaet Stuttgart, > > Nick. As we have stated that the value of Creg is undefined when popping the stack, whereas in many (but not all) cases it keeps its old value, we are not obliged to keep the same behaviour in future transputers. In fact, it is quite likely that on the H1, when we say undefined, the value will be next to impossible to predict, and be different every time the program is run. It is not (just :->) that we are being awkward, just that we are making the most of the instruction set as currently defined. malc. P.S. As with everything that I say, this is probably unrelated to official Inmos policy. Standard disclaimers apply. Malcolm Boffey, Transputer Group, Inmos. | Inmos Ltd, UK: malc@inmos.co.uk | 1000 Aztec West, Almondsbury, US: malc@inmos.com | Brisol BS12 4SQ. UUCP: ...uunet!mcsun!ukc!inmos!malc | Tel. +44 454 616616 x522