RESTRICTIONS

This summarizes restrictions  with  the  V4A  release.   Where
possible, temporary solutions are described.



PROBLEM:  The following code fragment

                d = 0;
                .....
                WHILE .d NEQ 0 DO
                    BEGIN
                    ....
                    x = 66 / .d;        ! Assume "d" never written
                    ...
                    IF .y THEN EXITLOOP
                    END

          will cause a zero-divide exception at  execution  time  when
          compiled  using  normal optimization.  The compiler believes
          that the expression "66/.d" is loop invariant and moves  the
          computation out of the loop.

SOLUTION: This is a restriction in V4A.  In this particular case,  the
          expression could be rewritten as:

                WHILE 1 DO
                    BEGIN
                    .....
                    IF .d EQL 0 THEN EXITLOOP;
                    ....
                    x = 66 / .d;
                    .....
                    END;

          In this case, the expression cannot  be  moved  out  of  the
          loop.




PROBLEM:  Incorrect code generated for structure  definitions  of  the
          form:

                STRUCTURE BAD[I,P,S]= [%UPVAL]
                    (IF .I THEN BAD ELSE BAD + .BAD<16,16>)<P,S>;

                OWN X: BAD[];
                LOCAL T;

                T = .X[.T,0,12];

          "X" is loaded into a register in the  THEN-branch,  but  the
          ELSE-branch uses the register without loading it.

SOLUTION: This is the result of a design flaw  in  the  way  structure
          references  are  expanded.  BLISS semantics guarantee that a
          structure actual-parameter is evaluated only once.  This  is
          implemented  by treating the first occurrence of a structure
          formal  as  if  it  was  a  BIND  declaration.   The   other
          occurrences  of  the structure formal are then treated as if
          they were uses of the "imaginary" bind-name.  This choice of
          implementation  fails  when  the  first  occurrence  of  the
          structure formal is in conditional flow!  The problem can be
          avoided by insuring that the first occurrence of each formal
          is outside  of  conditional  flow.   The  example  structure
          should be written as:

                STRUCTURE GOOD[I,P,S] = [%UPVAL]
                    (GOOD; IF .I THEN GOOD ELSE GOOD+.GOOD<16,16>)<P,S>;

          Note that the  "structure-name"  is  the  zero-th  structure
          formal  parameter.  The formals "I", "P" and "S" are already
          outside  of  conditional  flow,  so   they   are   processed
          correctly.   This  change  will  cause  the  compiler to use
          slightly  more  memory,  but  the  resulting  code  will  be
          correct.   There  should  be  no  reduction  in optimization
          either.

          Be aware that there is no problem when the conditional  flow
          is  constant-folded  at  compile-time,  or  when there is no
          conditional flow in the structure body.