🚀 go-pugleaf

In article <1126@inmos.co.uk (Hubert Matthews) writes:
>
>One of the problems with porting a non-transputer C compiler to the
>transputer is the transputer's evaluation stack.  One can simulate
>registers using on-chip RAM...
>                                  ...If, on the other hand, one uses the
>stack for expression evaluation, then one has to be very careful about
>stack overflow (the stack is only three elements deep).  A peephole
>optimiser would clean up a lot of the loads and stores associated with
>the first approach, but the second approach would need a quite
>different code generation algorithm.
>

The compilers we have written at Inmos use the approach outlined in 
``The transputer Instruction Set: a compiler writers' guide''. (Surprise,
surprise, we designed the machine, we wrote the book, we implemented 
the compiler). This approach is the second one outlined above. 

Variables live in the (local) workspace and the evaluation stack is
used  to evaluate expressions. It is very easy for a compiler to
introduce temporary variables if an expression is sufficiently
complicated that it cannot be evaluated in three registers. The
compiler can make use of the commutativity of certain operators to 
minimise the introduction of temporaries.

The Compiler Writers Guide also sets out the best way to load the 
three registers for procedure calling, or in order to execute an
instruction with three parameters (such as `long shift' or `input').

All these methods involve using recursive register counting algorithms
which determine the number of registers need to evaluate an expression.
Certain features of the transputer instruction set simplify these
calculations, for example, in occam or C any variable, be it local,
non-local, or referenced via pointer, requires a single register to load
it. For example,
 
   ldl x            -- load local x; loads a local variable

   ldl static-chain -- load local static-chain
   ldnl x           -- load non-local x; loads variable off static chain

   ldl pointer
   ldnl 0           -- load variable via pointer

I know that other people have successfully used these methods. I also
know of at least one other compiler which uses another evaluation stack
based method quite sucessfully.

As to the simulation of registers by the workspace, this might work, but
it would still leave a number of problems about how best to compile code
which loaded registers; I suspect to this properly requires some sort of
counting algorithm, and once this is in place it should be milked for
all possible benefit! All-in-all, I'd advise following the text-book method



Roger Shepherd, INMOS Ltd   JANET:    roger@uk.co.inmos 
1000 Aztec West             UUCP:     ukc!inmos!roger or uunet!inmos-c!roger
Almondsbury                 INTERNET: roger@inmos.com
+44 454 616616              ROW:      roger@inmos.com OR roger@inmos.co.uk