69 lines
2.8 KiB
Text
69 lines
2.8 KiB
Text
- 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)); }
|
||
]]
|