Path: utzoo!attcan!uunet!mcvax!enea!dkuug!daimi!larsac
From: larsac@daimi.dk
Newsgroups: comp.sys.transputer
Subject: Bug in Inmos TDS version D700D
Message-ID: <1893@daimi.dk>
Date: 10 Jan 89 12:28:43 GMT
Sender: news@daimi.dk
Reply-To: larsac@daimi.dk ()
Organization: DAIMI: Computer Science Department, Aarhus University, Denmark
Lines: 181

To all users of the D700D product release of TDS:

There seems to be a serious bug in the D700D compiler.

The problem arises when using mutiple assignments, where the righthand 
side consist of a list of expressions. It must be emphased, that the 
expresions involved has to be of some complexity, in order to produce
the error.

For example, the following program segment is ok

     INT a, b, c:
     SEQ
       a, b, c := 1, 2, 3

    
but the one below sets the transputer error flag during compilation

     INT a, b, c:
     SEQ
       a, b, c := ((a+47)-47), ((b+147)-147), ((c+124)-124)


The problem is not restricted to expressions of type INT, also REAL64 
is affected. REAL32 has not been tested.

Another (more subtle) error, that may be a sideeffect of the one above,
is the return of a expresionlist in functions.

Take for example the segment below:

     INT, INT FUNCTION Id(VAL INT a, b)
       VALOF
         SKIP
         RESULT a, b
     :

     INT i, j:
     SEQ
       i := 1
       j := 2
       i, j := Id(i, j)

This will work as expected, ie the values of i and j will remain the same
after the call of Id. Likewise will the segment
 
     INT, INT FUNCTION Id(VAL INT a, b) 
       VALOF 
         SKIP 
         RESULT ((a+47)-47),((b+147)-147)
     :   
 
     INT i, j:   
     SEQ 
       i := 1 
       j := 2 
       i, j := Id(i, j)  
 
but if we instead take the segment

     REAL64, REAL64 FUNCTION Id(VAL REAL64 a, b) 
       VALOF 
         SKIP 
         RESULT ((a+47.0(REAL64))-47.0(REAL64),((b+147.0(REAL64)-147.0(REAL64))
     :   
 
     REAL64 i, j:  
     SEQ 
       i := 1.0 (REAL64) 
       j := 2.0 (REAL64) 
       i, j := Id(i, j) 
 
will the values of i and j after the call of Id be 2.0 and 1.0 respectively,
ie the expressionlist returned by Id is reversed.

A set of variations of the error can be obtained, by mixing INT and REAL64
in the expressionlist. This way all results, from correct ones, over 
reversal of the list, to undefined values, can be generated.

Note that these errors do not set the transputer error flag, it 'just' 
produces some inpredictible results at runtime.
 

One way to avoid the errors seems to be:
  
  Do not use multiple assignments.
  In case you have to (functions returning more than one argument), you
  can rewrite the functions, such that there is no (complex) expressions
  in the RESULT section. That is, instead of the REAL64 function above that 
  failed, you could write

     REAL64, REAL64 FUNCTION Id(VAL REAL64 a, b)  
       REAL64 r1, r2:
       VALOF  
         SEQ
           r1 := ((a+47.0(REAL64))-47.0(REAL64))
           r2 := ((b+147.0(REAL64))-147.0(REAL64))
         RESULT r1, r2
     :
 
     REAL64 i, j:   
     SEQ  
       i := 1.0 (REAL64)    
       j := 2.0 (REAL64)  
       i, j := Id(i, j)  
  
  which will work properly.


Our system consists of a B007 motherboard, attached to a IBM XT286, mounted
with one B404 TRAM running the TDS and and a number of B401 TRAM's. 
The TDS version i the D700D release, dated 9th May 1988.

----------

Now we are at it: Is there anyone, who has experience with the GUY 
construct inside functions?
We have a problem adressing function parameters using their symbolic
names. The compiler accepts the names, but it seems to produce some
wrong code.
There seems to be some problems adressing function parameters with their
symbolic names. That is, the function, 

     REAL64 FUNCTION test(VAL REAL64 a)
       REAL64 r:
       VALOF
         r := a
         RESULT r
     :

produces the following disassembled code

     AJW -3
     LDL 4     -- begin assignment
     FPLDNLDB 
     LDLP 0
     FPSTNLDB  -- end assignment
     LDLP 0
     FPLDNLDB
     AJW 3
     RET

while the following function, that should do the same job,

     REAL64 FUNCTION testGUY(VAL REAL64 a)
       REAL64 r:
       VALOF
         GUY -- r := a
           LDL a
           FPLDNLDB
           LDL r
           FPSTNLDB
         RESULT r
     :

produces following:

     AJW -3
     LDL 4     -- begin assignment
     LDNL 0    -- WHAT ???
     FPLDNLDB
     LDLP 0
     FPSTNLDB  -- end assignment
     LDLP 0
     FPLDNLDB
     AJW 3
     RET



---------------------------------------------------------------

With our best wishes:

                         Henrik Tolboel, Lars Christiansen 

                         Computer Science Department
                         University of Aarhus
                         Ny Munkegade
                         DK 8000 Aarhus C
                         Denmark