d0p1/ack
1
0
Fork 0
Code Issues Pull requests Packages Projects Releases Wiki Activity

Initial entry, txt1 oversight

Browse source
This commit is contained in:
dick 1988-07-04 15:30:12 +00:00
parent c10adfa7cf
commit 632b1b2c4b
1 changed files with 215 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

215
doc/int/txt1 Normal file
View file

@ -0,0 +1,215 @@
.\" Introduction
.\"
.\" $Header$
.NH
INTRODUCTION.
.PP
This document describes an EM interpreter which does extensive checking.
The interpreter exists in two versions: the normal version with full checking
and debugging facilities, and a fast stripped version that does interpretation
only.
This document assumes that the full version is used.
.LP
First the virtual EM machine embodied by the interpreter (called \fBint\fP) is
described, followed by some remarks on performance.
The second section gives some specific implementation decisions.
Section three explains the usage of the built-in debugging tool.
.LP
Appendix A gives an overview of the various warnings \fBint\fP gives,
with possible causes and solutions.
Appendix B is a simple tutorial on the use of \fBint\fP.
A separate manual page exists.
.PP
The document assumes a good understanding of what EM is and what
the assembly code looks like [1].
Notions like 'procedure descriptor', 'mini', 'shortie' etc. are not
explained.
In the sequel, any word in \fIthis font\fP refers to the name of a
variable, constant, function or whatever, used in the source code under
the same name.
.LP
To avoid confusion: \fBint\fP interprets EM machine language (e.out files),
\fInot\fP the assembly language (.e files) and \fInot\fP the compact
code (.k files).
.NH 2
The virtual EM machine.
.PP
The memory layout of the virtual EM machine represented by the interpreter
differs in details from the description in [1].
Virtual memory is split up into two separate spaces:
one space containing the instructions,
the other all the data, including stack and heap (D-space).
The procedure descriptors are preprocessed and stored in a separate array,
\fIproctab[]\fP.
Both spaces start off at address 0.
This is possible because pointers in the two different spaces are
distinguishable by context (and shadow-bytes: see 2.6).
.NH 3
Instruction Space
.PP
Figure 1 shows the I-space, together with the position of some important
EM registers.
.Dr 12
NEXT --> |________________| <-- DB \e
| | |
| | | T
| | <-- PC |
| Program | | e
| | |
| Text | | x
| | |
| | | t
0 --> |________________| <--(PB) /
.Df
\fI Fig 1. Virtual instruction space (I-space).\fP
.De
.PP
The I-space is just big enough to contain all the instructions.
The size needed for the program text (\fINTEXT\fP) is found from the
header-bytes of the loadfile.
Legal values for the program counter (\fIPC\fP) consist of all
addresses in the range from 0 through \fINTEXT\fP \- 1.
If the \fIPC\fP is made to point to an illegal address, a trap will occur.
.NH 3
The Procedure Table
.PP
The \fINProc\fP constant indicates how many procedure descriptors there
are in the proctab array.
Elements of this array contain for each procedure: the number of locals, the
entry point and the entry point of the textually following procedure. This is
used in testing the restriction that the program counter may not wander from
procedure to procedure.
.NH 3
The Data Space
.PP
Figure 2 shows the layout of the data space, which closely conforms to the EM
Manual.
.Dr 36
__________________
maxaddr(psize) --> | | <-- ML \e
| | | S
| Locals | | t
| & | | a
| RSBs | | c
| | | k
|________________| <-- SP /
. .
. .
. Unused .
. .
. .
. .
. .
. .
. Unused .
. .
. .
|________________| <-- HP
| | \e
| Heap | |
|________________| <-- HB |
| | | D
| Arguments | |
| Environ | | a
| _ _ _ _ | |
| | | t
| | |
| | | a
| Global data | |
| | |
| | |
0 --> |________________| <--(EB) /
.Df
\fI Fig 2. Virtual dataspace (D-space).\fP
.De
.PP
D-space begins at address 0, and ends at the largest address
representable by the pointer size (\fIpsize\fP) being used;
for a 2-byte pointer size this maximum address is
.DS
((2 ^ 16 \- 1) / word size * word size) \- 1
.DE
for a 4-byte pointer size it is
.DS
((2 ^ 31 \- 1) / word size * word size) \- 1
.DE
(not 2 ^ 32, to allow illegal pointers to be implemented in the future). The
funny rounding construction is required to make ML+1 expressible as the
initialisation value of LB and SP.
.PP
D-space is split into two partitions: Data and Stack (indicated by the
brackets).
The Data partition holds the global data area (GDA) and the heap.
Its initial size is given by the loadfile constant SZDATA.
Some space is added to it, because arguments and environment are
stored here also.
This total size is static while interpreting.
However, as the heap may grow during execution (e.g. caused by dynamic
allocation) this results in a variable size for the Data partition.
Initially, the size for the Data partition is the sum of the space needed
by the GDA (including the space needed for arguments and environment) and
the initial heapspace.
The lowest legal Data address is 0; the highest \fIHP\fP \- 1.
.LP
The Stack partition holds the stack.
It begins at the highest available D-space address, and grows
towards the low addresses, so the Stack partition is of variable size too.
The lowest legal Stack address is the stackpointer (\fISP\fP),
the highest is the memory limit (\fIML\fP).
.NH 2
Physical lay-out
.PP
Each partition is mapped onto a piece of physical memory with the
same name: \fItext\fP (fig. 1), \fIstack\fP and \fIdata\fP (fig. 2).
These are the storage structures which \fBint\fP uses to physically
store the contents of the virtual EM spaces.
Figure 2 thus shows the mapping of D-space onto two
different physical parts: \fIstack\fP and \fIdata\fP.
The I-space is represented by one physical part: \fItext\fP.
.LP
Each time more space is needed, the actual partition is reallocated,
with the new size being computed with the formula:
.DS
\fInew size\fP = 1.5 \(mu (\fIold size\fP + \fIextra\fP)
.DE
\fIextra\fP is the number of bytes exceeding the \fIold size\fP.
One can prove that using this method, there is a
linear relationship between allocation time and needed partition size.
.PP
A virtual D-space starting at address 0 is in correspondence with
the definition in [1], p. 3\-6.
The main reason for having D-space start at address 0, is that it induces
a one-one correspondence between the heap \- and GDA
addresses on the virtual machine (and hence the definition) on one hand,
and the offset within the \fIdata\fP partition on the other.
This implies that no extra calculation is needed to perform load and
storage operations.
.LP
Some calculation however cannot be avoided, because the stack part of
the D-space grows downwards by EM definition.
The first address of the virtual stack (\fIML\fP, the maximum address for
the given \fIpsize\fP) is mapped onto the
beginning of the \fIstack\fP partition.
When the stack grows (i.e. EM addresses get lower), the offset within the
\fIstack\fP partition gets higher.
By taking offset \fIML \- A\fP in the stack partition, one obtains the
physical address corresponding to some virtual EM (stack) address \fIA\fP.
.NH 2
Speed.
.PP
From several test results with both versions of the interpreter, the
following may be concluded.
The speed of the interpreter depends strongly on the type of
program being interpreted.
If plain CPU arithmetic is performed, the interpreter is
relatively slow (1000 \(mu the cc version).
When stack manipulation is at hand, the interpreter is
quite fast (100 \(mu the cc version).
.LP
Most programs however will not be this extreme, so an interpretation
time of somewhere between 300 and 500 times direct execution
for a normal program is to be expected.
.LP
The fast version runs in about 60% of the time of the full version, at the
expense of a considerably lower functionality.
Tallying costs about 10%.