Last modified on Tue Apr 15 11:18:04 PDT 1997 by heydon

This file documents bugs and/or inefficiencies in the Juno machine.

BUGS ==========================================================================

  o On the Alpha, the machine sometimes crashes with floating point
  exceptions. The same errors do not occur on the DECstation. For example,
  when the test file "juno-machine/tests/rt/src/bc-17.txt.in" computes 38
  factorial, it crashes because the result would be too large for a
  single-precision real. On the DECstation, the result is IEEE "Infinity".

Done on Tue Jan 28 10:45:02 PST 1997 by heydon
  o The current design allowed functional external procedures to be
  considered undefined. This made external functional procedures
  different from user-defined functional procedures. So I changed the
  implementations of the CALLEXT and APPLY bytecodes in the machine to
  simply report the run-time error "Failed External Procedure"
  whenever a call to an external procedure failed.

Done on Mon Oct 14 13:30:08 PDT 1996 by heydon
  o Tim Mann reported that the Juno solver was failing for a
  particular drawing he was producing. The procedure he was calling
  worked for some values of its arguments, but not all. By
  investigating the solver log, Greg and I determined that the test to
  stop the Newton iteration when the changes to the variables got too
  small was kicking in too soon. In particular, the value of the
  constant "RedundantSolve.MinDelta" was too large. We made it an
  order of magnitude smaller, and Tim's example started working. The
  termination test is mostly a performance enhancement. That is,
  making it too small would adversely affect performance, not
  correctness, so our change was certainly safe. On the other hand,
  making the value too large can cause the solver to fail when it
  would actually succeed if it had been allowed to continue, as
  happenned in Tim's case.

Done on Fri Jun 30 20:10:46 PDT 1995 by heydon
  o The Juno machine could crash in various ways if an uninitialized
  variable was used [davidm]. For example, since the "RTVal.FromPair"
  procedure requires both its arguments to be non-NIL, any pair
  expression involving an uninitialized variable would cause a crash.
  This is because every local value is given an initial value of
  Modula-3 NIL by the "PUSHM3NIL" instruction at the start of each
  procedure. I added a "PushedNIL" exception and a "UsedUninitialized"
  run-time error to the Juno machine. The error is signalled whenever
  an attempt is made to push Modula-3 NIL onto the stack.

Done on Mon Jun 12 18:23:30 PDT 1995 by heydon
  o Changed INT predicate to evaluate true only when its argument is
  an exact integer.

Done on Fri Jun  9 11:32:24 PDT 1995 by heydon
  o Marc Najork and Hui Ma reported that the solver would crash if the
  constraint system supplied to "JunoSolve.P" contained a redundant
  equality constraint (i.e., an equality constraint that could be
  deduced from other pair and equality constraints). The bug was easy
  to fix: the code for processing equality constraints was not
  guarding against the possibility that the two "JunoSolve.Var"'s
  being merged were already known to be equal (i.e., had identical roots).

Done on Tue May 30 22:31:16 PDT 1995 by heydon
  o The INT predicate in JunoRT.m3 was still buggy. It was not
  returning TRUE for floating values with magnitudes slightly less
  than true integers.

Done on Thu May  4 09:49:41 PDT 1995 by heydon
  o Fixed a bad bug in the implementation of the INT predicate in
  JunoRT.m3. The predicate would always evaluate true if its argument
  was positive. Also, it would crash with a floating point error on
  Alpha if its argument was 0.

Done on Wed Feb  8 15:33:16 PST 1995 by heydon
  o There was a bug in the "RTVal.Dispose" procedure that was causing
  incorrect values to be printed when the global "debug" switch was on.

Done on Tue Feb  7 18:42:06 PST 1995 by heydon
  o The equality test between texts was broken [ramshaw]. We were
  comparing pointers instead of using "Text.Equal".

Done on Tue Jan 10 14:59:26 PST 1995 by heydon
  o Point values in the current command are not getting unparsed to
  full precision, so freezing a point after it has been "solved" can
  trigger a guard failure. Changed "JunoValue.Unparse" to unparse real
  values to their full precision [ramshaw].

Done on Mon Sep 26 14:21:07 PDT 1994 by heydon
  o The solver sometimes "solves" constraints on the ATAN function, even when
  the solution it produces does not satisfy the constraint! See the test file
  "juno-machine/tests/nonlinear/src/atan.txt.in". The bug was in the
  code for computing the derivative of ATAN: the comment was correct,
  but the code had multiplications where there should have been divisions.

Done on Fri Aug 26 01:32:56 PDT 1994 by heydon
  o The solver is not correctly asserting the types of arguments to
  numeric functions, so even though the constraint "0 = A + x", where
  "A" is a non-numeric constant should fail, it is causing a crash
  [gnelson].

Done on Tue Jun 14 18:30:06 PDT 1994 by heydon
  o The machine is crashing when either of the arguments to "&" is not a
  text [gnelson]. The problem is that the "Pop..." routines in "JunoRT" need
  the "err" argument to be by "VAR".

Done on Fri Oct  8 11:25:07 PDT 1993 by heydon
  o The machine crashes because the "undefined term" address "a_ut" is
  not being set when a call to a FUNC is an argument to a call to a built-in
  (external) procedure, and the FUNC call is undefined.

  The fix was to add a new machine instruction called "UJUMP" to be used only
  on return from calls to user-defined functions. This instruction is like
  "FJUMP", but it has the side-effect of setting "a_ut".

Done on Sat Oct  2 14:37:58 PDT 1993 by heydon
  o The "a_ut" address in the machine is not being set if a user-defined
  function is compiled as an expression, and the result of the call to the
  function is undefined.

TO DO =========================================================================

Done on Fri Mar 29 14:07:29 PST 1996 by heydon
  o Changed interfaces to "JunoValue.Unparse" and "JunoValue.UnparseToFmt"
  to take an explicit precision to which real values are unparsed.

Done on Wed Feb  8 15:34:27 PST 1995 by heydon
  o Added comments to the "RTVal" interface, including comments that
  the arguments to the "FromText" and "FromPair" procedures be non-NIL.
  Also added assertions to those procedures to test that the
  preconditions are met. [gnelson]

Done on Fri Dec 16 14:28:56 PST 1994 by gnelson
  o The solver was changed to solve redundant constraints.

Done on Tue Jun 14 09:49:31 PDT 1994 by heydon
  o Make the "JunoRT.InternalState" a subtype of "RTVal.T" so that the
  run-time stack can consist entirely of "RTVal.T"'s and we don't have to pay
  the cost of a narrow on stack accesses.

Done on Mon Jun 13 17:32:12 PDT 1994 by heydon
  o Change the "JunoArgs" interface to commerce in "RTVal.T"'s instead of
  "JunoValue.T"'s. Also, create separate procedures for each type of value to
  avoid the narrow cost. Moreover, the "Read..." procedures can include a
  BOOLEAN (*INOUT*) VAR to indicate an error. For example:

    PROCEDURE ReadPair(i: CARDINAL; VAR (*INOUT*) err: BOOLEAN): RTVal.Pair
    (* Return the actual parameter with index "-i" if it is a pair. Otherwise,
       set "err" to TRUE; in this case, the return result is undefined. *)

Done on Fri Jun 10 11:28:33 PDT 1994 by heydon
  o Rename "BC.PUSHNIL" -> "BC.PUSHM3NIL", and add new instructions
  "BC.PUSHNIL" and "BC.PUSHNUM" for pushing Juno NIL and Juno numbers. The
  latter instruction reads the number directly from the bytestream. This will
  probably require adding a new routine to the "JunoMarshal" interface for
  reading/writing "JunoValue.Real"'s from/to the bytestream.

Done on Wed Jun  1 10:02:44 PDT 1994 by heydon
  o Add "NEWCL", "NEWEXTCL", "CLOSE", "APPLY", and "CLDECSP" bytecodes for
  implementing closures.

Done on Thu Apr 11 18:34:15 PDT 1994 by heydon
  o Changed precision used to print real numbers to a small number of
  significant figures (3 or 4). Got rid of special test that was rounding to
  integers [heydon].

Done on Thu Aug 19 17:39:49 PDT 1993 by heydon
  o ATAN(x) => ATAN(y, x). This will require changes to the machine and solver
  as well as to the compiler.

INEFFICIENCIES ================================================================

  o Make RTVal.T's untraced so that the garbage collector never has to touch
  them. This may be unnecessary if the collector's generational properties are
  good enough.

Done on Thu Apr 10 09:52:22 PDT 1997 by heydon
  o Added WITH statements to RedundantSolve.EvalConstraints procedure
  for efficiency.

Done on Thu Apr 10 09:47:22 PDT 1997 by heydon
  o Added WITH statement to inner loop of RedundantLSolve.Pivot
  procedure for efficiency.

Done on Wed Apr  9 12:55:13 PDT 1997 by heydon
  o Changed m3makefile so this library is now compiled with
  optimization for efficiency.

Done on Wed May 10 18:48:47 PDT 1995 by heydon
  o Changed "RTVal.FromJV", "RTVal.ToJV", and "RTVal.Equal" to use
  iteration instead of recursion so fewer stack frames would be used
  when converting/comparing long lists. These procedures were
  occasionally causing stack overflows.

Done on Wed Aug 17 15:16:19 PDT 1994 by heydon
  o Change the implementation of UnionFind to use the QuickFind algorithm.

Done on Mon Jun  6 09:35:31 PDT 1994 by heydon
  o The run-time is NEW'ing too many intermediate Juno values. Fix this by
  writing a RTVal interface for allocating run-time values from an avail
  list. Also, add a call to "RTVal.Dispose" when the machine finishes running.

Done on Mon Jun  6 09:34:06 PDT 1994 by heydon
  o The solver is NEW'ing too many "JunoSolve.Var"'s. If possible, allocate
  and deallocate them explicitly from/to an avail list.

Done on Tue Mar 30 11:30:35 PST 1993 by heydon (actually done a while ago)
  o Value table has duplicate entries; it should share them.

Done on Mon Feb 15 18:03:17 PST 1993 by heydon
  o The run-time should report stack overflow as a normal trap code, instead
  of an exception.
