Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!mcsun!ukc!inmos!malc@bilbo.inmos.co.uk
From: malc@bilbo.inmos.co.uk (Malcolm Boffey)
Newsgroups: comp.sys.transputer
Subject: Re: More undocumented instructions
Message-ID: <5356@ganymede.inmos.co.uk>
Date: 5 Apr 90 20:25:14 GMT
References: <2076@ifi.informatik.uni-stuttgart.de> <3159@castle.ed.ac.uk>
Sender: news@inmos.co.uk
Reply-To: malc@inmos.co.uk (Malcolm Boffey)
Organization: INMOS Limited, Bristol, UK.
Lines: 28

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