Initial entry

diff --git a/util/int/TODO b/util/int/TODO
new file mode 100644 (file)
index 0000000..296727d
--- /dev/null
+++ b/util/int/TODO
@@ -0,0 +1,69 @@
+-      Reduction of repetetivity in the code
+Before making any major changes to the interpreter, it would be good to
+implement Model 3 (Intelligent Calls), as described in the interpreter
+documentation.  This will reduce the bulk of the code considerably, since then
+there will be only one routine for each instruction.  Now identical changes
+have to be made in n places.
+
+
+-      Shadow bytes with internal values
+The biggest problem with the interpreter is that undefinedness is not
+transitive.  A warning is given if an undefined value is used, but then the
+interpreter goes on to use the (zero) value as if nothing had happened.  The
+reason is that internal values in the interpreter have no shadow bytes, and
+consequently the undefinedness is lost as soon as a value is passed to an
+operation.  Likewise the type is lost, which makes it impossible to do good
+type cheking on pointers.  If internal values would have a shadow byte (only
+one per values is needed), we could have a shadow bit signifying "derives from
+null pointer", which could be checked when the pointer is dereferenced.
+Presently only the value of the pointer is checked.
+
+
+-      Name generation upon forking.
+At present there is an ad-hoc mechanism for generating new file names for
+int.log and int.mess and a new variable name for LOG= upon forking.  This
+mechanism is not well localized and does not generalize immediately to other
+file names like int.tally and int.core.  Another consequence is that the AT=
+facility is presently implemented as a patch.
+
+
+-      Integration of memory access
+Presently each memory access consists of at least three calls, one to check
+the shadow byte, one to store the data and one to rewrite or update the shadow
+byte; each of these do the same address evaluations etc.   There should
+probably be routines for integrated writing and reading of bytes.
+
+
+-      Improvements of warnings
+Presently warnings are indicated by a single number, in warn.h.  This is often
+too little information.  The warning should be a printf format, and warning()
+should accept a variable number of parameters.
+
+
+-      There seems to be no way of obtaining the largest possible double
+on a machine in a system-independent way (except, perhaps, for including
+<math.h>). For the time being there is a #define MAXDOUBLE in do_fpar.c.
+
+
+-      Program to process the int.tally file
+
+
+-      Program to process int.core; also, define a more proper format for the
+int.core file.
+
+
+-      Some esthetic problems
+       -       The system call umount is called unmount on some systems, or
+               even called differently in different libraries on the same
+               system. It is not clear to me who is to blame, nor if that
+               would help.
+
+
+
+
+\f
+[[
+Proposed code to be generated by mkswitch.c;
+type to be had from /ur/em/etc/em_table.
+DoXXX[01](par) long par { type arg = (LOG(("@X9 XXX %lt", par)), arg_t(par)); }
+]]