70 lines
2.8 KiB
Plaintext
70 lines
2.8 KiB
Plaintext
|
- 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)); }
|
|||
|
|
]]
|