IAN@vax1.esprit.southampton.ac.UK (09/27/88)
The following program illustrates a rather interesting 'feature' of the T414,
which we noticed recently, which I expect not everyone is aware of:
PRI PAR
STOP
SKIP
If you compiled this as an EXE (with HALT on error set) under TDS, running on
a T414, and ran it, what would you expect to happen - Deadlock? Transputer
error flag set? No way - the program terminates and returns you to TDS!
This came to light when someone observed that array bound violations in high
priority processes do not always (but sometimes do) crash the program with
the message "Transputer error flag set". After a considerable amount of
head-scratching we realised that this must be due to a combination of the
facts that:
a) The transputer saves the error flag when a low priority process is
pre-empted by a high priority process, and restores it again when the low
priority process resumes.
b) The processor does not halt if the error flag is set during the execution
of a high priority process.
We were not previously aware of fact b), but this has subsequently been
confirmed by talking to someone from INMOS. Apparently this was how the
transputer was originally specified to behave, although it is clearly
undesirable. Rather than change the silicon, it was documented (I'm not sure
where) as a 'feature' of the T414. The T800 behaves as you would expect,
however (not as above!).
The reason for the intermittent behaviour of application programs with
array bound violations is illustrated by running slightly different version
of the original program:
PRI PAR
SEQ
STOP
SEQ i = 0 FOR 5000000
SKIP
SKIP
When run on one of our (home-built) TDS systems, which has the error pin
connected to a light, as well as activity lights for internal/external
memory, the pattern is clear. What happens is that the error light comes on
straight away, which memory is busily accessed for a few seconds. At the
same time, the message "Transputer error flag set" comes up on the PC screen.
After a few seconds, memory ceases to be accessed, and the error light goes
out again.
Clearly, the only reason the original program returned to TDS was that the
error flag was being set for such a short time that the server (which works
by polling) did not notice it. By rights, of course, the processor should
have halted anyway.
I hope this information saves someone some time in interpreting the strange
behaviour of an errant high priority process.
Regards,
Ian Glendinning
+-----------------------------------------------------------------------------+
| Ian Glendinning JANET: ian@UK.AC.soton.esp.v1 |
| Concurrent Computation Group BITNET: ian%UK.AC.soton.esp.v1@AC.UK |
| Electronics & Computer Science UUCP: ...!mcvax!sot-cm!igl |
| The University of Southampton other: ian@v1.esp.soton.AC.UK |
| SOUTHAMPTON SO9 5NH |
| United Kingdom Phone: +44 703 559122 extn 3368 |
+-----------------------------------------------------------------------------+