Path: utzoo!attcan!uunet!mcvax!ukc!warwick!inmos!conor
From: conor@inmos.co.uk (Conor O'Neill)
Newsgroups: comp.sys.transputer
Subject: Re: Bug in Inmos TDS version D700D
Message-ID: <701@brwa.inmos.co.uk>
Date: 13 Jan 89 17:37:35 GMT
References: <1893@daimi.dk>
Reply-To: conor@inmos.co.uk (Conor O'Neill)
Organization: INMOS Limited, Bristol, UK.
Lines: 88

In article <1893@daimi.dk> larsac@daimi.dk 
(Henrik Tolboel and Lars Christiansen)
pointed out a few problems with the D700D compiler.

The first is to do with multiple assignment:
>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)

This is a known bug. It is caused by the `unnecessary' brackets on the
right hand side of the assignment. The following code is OK:

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


The second problem is also a known bug. The compiler can sometimes
create incorrect code when compiling a FUNCTION on a T800 which returns
multiple results, at least one of which is REAL.
As the original poster correctly observed, the problem can be overcome
by copying all `complicated' result values into local variables, 
and returning those. For example:

>  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))
>  :   
 
This can be overcome by re-writing as

>  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
>  :
 
Both of these problems have been fixed, and any new releases of the
D700D will not have these problems.

Contact your distributor for an up-to-date bug list.

The problem concerning GUY code was caused by forgetting that
FPLDNLDB requires a POINTER to the variable to be loaded. 
Remember that GUY code is not exactly assembler; when you write
LDL a, the compiler inserts enough code to load a onto the stack.
It does not simply insert a LDL instruction, if a is not a local variable.
Similarly, LDLP a is translated to whatever sequence of instructions is
necessary to load the address of a onto the stack.
So to get the same effect as

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

you need to write

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

which both produce the following:

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

Conor O'Neill, Software group, INMOS Ltd.