lr@cs.brown.edu (Luigi Rizzo) (03/21/91)
I'm posting this to comp.sys.transputer and to the 3L support (should be support@threel.co.uk). Does anyone have experience in running the 3L C compiler on a T800 ? We have the 3L C compiler (apparently v.2.0), bought in summer 1989. The copyright message in file TC.B4 says: Transputer C Compiler, Copyright (C) 3L Ltd 1988 CC_Transputer V2.0 Also, somewhere in the same file there is the following line: CC_T4 V0.6 (beta test version) All the products (compiler, linker, config. etc) work fine on our Inmos boards based on the T414. I tried to port the compiler on a T800 board with 4MB ram, hosted on a Unix system, and had the following problem: the two programs TC.B4 and DECODE.B4 do not work, and seem to lock at some point (all the others work fine, including the executables produced by the compiler). Some work on the AFSERVER to trace the communication between the Transputer and the host revealed that both programs stop communicating after the following sequence of calls (immediately after the boot): RUNTIMEDATA_CMD OPENOUTPUTSTREAM_CMD OPENINPUTSTREAM_CMD OPENINPUTSTREAM_CMD OPENOUTPUTSTREAM_CMD READBLOCK_CMD READTIME_CMD This happens no matter the value returned by the readtime function (which indeed works, being used in some programs of mine that do run correctly -- and I could see the READTIME_CMD call in the trace). The error flag (tested with -:e on afserver) is apparently not set. Noticeably, the "beta test version" string is only present in those two programs, and also the other programs do not seem to have the same sequence of calls at the beginning. The way the Transputer locks is such that, after writing the reply message for the call, only one more word can be written to the link. It is possible to force a stack dump by making AFSERVER return OPERATIONFAILED_ERR in response to the READTIME_CMD call, in this case the reply from the transputer running TC.B4 on a T800 is something like: % event 9 3 99 000001E1 SIGNAL SIGNAL 000001FD FILEIO CHECKRESULT 0000004D CPUTIME ICLOCK 00000061 INIT MAIN and something similar for DECODE.B4 . Unfortunately, I don't know what to do with this, as the only tool that might have helped me (DECODE) is broken too (this is a consequence of the Murphy law, I think). I'm prone to think that this is a bug of the compiler, which has been likely fixed in subsequent releases. Also, the "beta test" string in the executables makes me think that the version we have bought is not that good... I hope that either there is a binary patch that can be applied to the executables, or that 3L can solve the problem without having to *buy* a new release for a bug fix. Luigi Rizzo ================================================================== Luigi Rizzo Brown University & Univ. di Pisa e-mail: lr@cs.brown.edu, luigi@iet.unipi.it ==================================================================