******************** KnownBugs ********************
Last Change: Wed May 17 17:44:15 1995


The current version of Parallaxis-III on this server is a much more
stable version than the one from September. But remember it is not yet
the final version. There still exist bugs. Most of them are missing
consistency checks and missing error messages. The general rule is: if
you enter correct Parallaxis source code you should get correct
running code.

This file contains a summary of the bugs we know of. We're working on
them at the moment.

If you encounter some strange behaviour of the compiler, please first
check the list below if it's already a known bug before reporting it
to us. If you think you have found a new bug please report it to:

  keller@informatik.uni-stuttgart.de    or
  braunl@informatik.uni-stuttgart.de

======================================================================


[This is the start of the BUGS-list.]

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

The RETURN of a function-procedure always returns. This is wrong, only
the active PEs should virtually return and the procedure should return
only when all PEs have virtually returned.

Example:

CONFIGURATION conf[1..20];

PROCEDURE f():conf OF INTEGER;
BEGIN
  IF ID(conf)>10 THEN
     RETURN 1;
  ELSE
     RETURN 5;
  END; (* IF *)
END f;

This should return 10x 1 and 10x 5, but it only returns 10x 1 and 10x
undefined values, because the RETURN in the THEN part causes the whole
procedure to return without executing the ELSE part.

You can work around this problem by collecting the result in a
variable and returning at a single point.

CONFIGURATION conf[1..20];

PROCEDURE f():conf OF INTEGER;
VAR h: conf OF INTEGER;
BEGIN
  IF ID(conf)>10 THEN
     h := 1;
  ELSE
     h := 5;
  END; (* IF *)
  RETURN h;
END f;

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

If you enter a string in ReadString that is longer than the array of
characters given to it, the additional characters overwrite the memory
behind the array. Be sure to have arrays that are large enough.

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

There are problems when using AND and OR in parallel boolean
expressions. Be sure to use enough parentheses, then it works ok.
(=> missing error message)
This problems seems to be solved now. But further testing is needed.
----------------------------------------------------------------------

Don't use identifiers that are also used in Connection computations
without declaring them. (=>missing error message)

E.g.
  MODULE bug_con;
  CONFIGURATION list[1..5];
  CONNECTION next: list[i] -> list[i+1];
   
  BEGIN
    i := 1;  (* <-- not declared but no error is reported !!! *)
  END bug_con.

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

There are lots of runtime range checks missing, and those created show
the line of the C-file, not the line of the Parallaxis-file.

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

If you declare variables from an open configuration, you only get an
error message from the C-compiler instead of the Parallaxis-compiler.

  CONFIGURATION grid[*],[*];
  VAR x: grid OF INTEGER;   (* <--- This is not allowed *)

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

ID, DIM, ... don't generate errors when called with an open
configuration.

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

DIM(config, x) gives no runtime error when called with x>RANK(config).

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

Type checking is missing in record constants:

  TYPE com = RECORD re,im: REAL END;
  CONST i  = com(0,1);
                 ^^^ should be REALs, but no error reported

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

If you have a procedure with a vector VAR-parameter, you must not
call it with a field of a record as in this example:

  MODULE bug_record;
  CONFIGURATION list[1..9];
  
  TYPE Rec = RECORD x,y: INTEGER; END; (*RECORD*)
       
  PROCEDURE f(VAR x: list OF INTEGER);
  END f;
  
  VAR a: list OF Rec;
  
  BEGIN
    f(a.x);   (* wrong *)
  END bug_record.

This creates an error in the C-compiler pass. And this is a rather
severe problem, where we have no correct solution yet. The problem is
that such a record field is stored together with the other fields
of the record. This is different to the way a usual vector variable is
stored and so no pointer can be given to the procedure.

If the parameter is call-by-value (no VAR), everything works fine.

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


The check whether declarations in the DEFINITION MODULE and
IMPLEMENTATION MODULE match should be improved. Especially if you
import an identifier that does not exist in the DEFINITION MODULE,
this is not recognized.

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

If you compile a pair of .pd/.pm-files with option -c, the C-compiler
generates warnings:
gcc: -lp3: linker input file unused since linking not done
gcc: -lm: linker input file unused since linking not done

These warnings shouldn't be shown.

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

There may be problems if you create CASE label ranges that reach
MAX(INTEGER) or MAX(CARDINAL). The compiler may hang while generating
infinite case labels, slowly filling your disk.

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

The evaluation of expressions uses far too much help variables. This
can be improved. This is no bug, but it slows down the simulation.

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

Connections should only use the kind of indexes the configuration was
declared with. Here is an error message missing.

CONFIGURATION conf['A'..'H'],[0..255];
CONNECTION conn: conf[i,j]->conf[i,'x'];  (* wrong *)

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

Arrays that are declared local to a procedure may not have a procedure
parameter as a boundary. Here's also an error message missing.

  PROCEDURE p(x: INTEGER);
  VAR a: ARRAY [1..x] OF CHAR;    (* wrong *)

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

If you import an identifier via FROM, it should be allowed to refer to
it qualified. This is not possible at the moment.

  FROM mod IMPORT id;

  ... mod.id ...   (* Should be possible *)

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

In an assignment the expression on the right-hand side is evaluated
before any expression in the lvalue on the left-hand side. This should
be the other way round to guarantee the left-to-right evaluation rule.

E.g. 

  MODULE lefttoright;
  VAR i: CARDINAL;
      a: ARRAY[0..10] OF CARDINAL;
  PROCEDURE f():CARDINAL;
  BEGIN
    INC(i);
    RETURN i;
  END f;
  
  BEGIN
    i := 0;
    a[f()] := f();   (* results in a[2] := 1; should be: a[1] := 2 *)
  END lefttoright.

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

Modula-2 defines the evaluation of boolean expressions to be done
in the short form, i.e. the rest of the expression is not evaluated
when the result cannot change anymore. E.g.

  IF (a<b) AND (c<d) THEN ...

is internally evaluated like

  IF (a<b) THEN IF (c<d) THEN ...

Well, this is not necessarily true in Parallaxis. So don't rely on
this yet, especially when using vector expressions.

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

The Emacs Parallaxis mode should be finished and improved. Some
functions like compiling and indentation don't work correctly yet. But
the keyword completion and the hi-lighting work very well.

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

User defined REDUCE functions most probably don't work at the moment.
The generated code is very bad and incomplete.

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

The data exchange between different configurations using RECEIVE or
MOVE may create undefined values on PEs not receiving any value.

CONFIGURATION 
   c1[0..8];
   c2[0..9];

CONNECTION
   a: c1[i] -> c2[i];
   b: c1[i] -> c2[i DIV 2];

VAR x,y: c1 OF INTEGER;
    z:   c2 OF INTEGER;

...
  z := 0;
  z := MOVE.a(x) + MOVE.b:#SUM (y);      

Despite of the initialization with 0, at the end z contains only valid
values on PEs 0..4. PEs 5..9 are undefined. When transmitting data
from configuration c1 to configuration c2, there's no way to determine
any default value for those PEs not receiving any value. And so PE 9
receives no value from either the first (via a) or the second term
(via b), so it's undefined. PEs 5..8 receive a value from the first
term (via connection a), but there's no value from the second term
(via connection b), so they're undefined, too. An example using
numbers should make this point clear:

PE:       0   1   2   3   4   5   6   7   8       in c1
---------------------------------------------------------
a:        4   2   4   1   0   4   4   3   1
b:        2   3   3   1   0   4   0   3   2


PE:       0   1   2   3   4   5   6   7   8   9   in c2
---------------------------------------------------------
z:        0   0   0   0   0   0   0   0   0   0   after z:=0
1st term: 4   2   4   1   0   4   4   3   1   ?   MOVE.a(x)
2nd term: 5   4   4   3   2   ?   ?   ?   ?   ?   MOVE.b:#SUM (y)
z:        9   6   8   4   2   ?   ?   ?   ?   ?   after addition

It may seem that the values of z (all zeros) could be used as default
values in both data exchange operations. This is not true. The
expression on the right-hand side must be fully computable without
knowing anything about the left-hand side of the assignment, because an
expression can also occur in situations, where no left-hand side even
exists, e.g. as a parameter to a procedure call.

This problem is not exactly a bug. It is a restriction due to the
language design. As a result, the current version of Parallaxis-III
only guarantees to get no undefined values when exchanging data
within the same configuration. Here, the source value itself can be
used as default value for the target value.

Please remember, that SEND has no such problems, as it is a procedure.
By giving the target configuration explicitly by a variable, the
default values of the target can be directly used from this variable.

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

ABS() used to return CARDINAL result when called with an INTEGER. This
was not conform with the Modula-2 language report, where ABS should
return the type of its argument. 

This is now corrected.

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


======================================================================







[This is the end of the Bugs-File.]





