-	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.





[[
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)); }
]]