pxin1.n

早期freebsd实现

entry for the block.
The major parts of the stack frame are represented in Figure 1.1.
.so fig1.1.n
Note that the local variables of each block
have negative offsets from the corresponding display entry,
the ``first'' local variable having offset `\-2'.
.NH 2
The block mark
.PP
The block mark contains the saved information necessary
to restore the environment when the current block exits.
It consists of two parts.
The first and top-most part is saved by the
.SM CALL
instruction in the interpreter.
This information is not present for the main program
as it is never ``called''.
The second part of the block mark is created by the
.SM BEG
begin block operator that also allocates and clears the
local variable storage.
The format of these blocks is represented in Figure 1.2.
.sp
.so fig1.2.n
.PP
The data saved by the
.SM CALL
operator includes the line number
.I lino
of the point of call,
that is printed if the program execution ends abnormally;
the location counter
.I lc
giving the return address;
and the current display entry address
.I dp
at the time of call.
.PP
The
.SM BEG
begin operator saves the previous display contents at the level
of this block, so that the display can be restored on block exit.
A pointer to the beginning line number and the
name of this block is also saved.
This information is stored in the interpreter object code in-line after the
.SM BEG
operator.
It is used in printing a post-mortem backtrace.
The saved file name and buffer reference are necessary because of
the input/output structure
(this is discussed in detail in 
sections 3.3 and 3.4).
The top of stack reference gives the value the stack pointer should
have when there are no expression temporaries on the stack.
It is used for a consistency check in the
.SM LINO
line number operators in the interpreter, that occurs before
each statement executed.
This helps to catch bugs in the interpreter, that often manifest
themselves by leaving the stack non-empty between statements.
.PP
Note that there is no explicit static link here.
Thus to set up the display correctly after a non-local
.B goto
statement one must ``unwind''
through all the block marks on the stack to rebuild the display.
.NH 2
Arguments and return values
.PP
A function returns its value into a space reserved by the calling
block.
Arguments to a
.B function
are placed on top of this return area.
For both
.B procedure
and
.B function
calls, arguments are placed at the end of the expression evaluation area
of the caller.
When a
.B function
completes, expression evaluation can continue
after popping the arguments to the
.B function
off the stack,
exactly as if the function value had been ``loaded''.
The arguments to a
.B procedure
are also popped off the stack by the caller
after its execution ends.
.KS
.PP
As a simple example consider the following stack structure
for a call to a function
.I f,
of the form ``f(a)''.
.so fig1.3.n
.KE
.PP
If we suppose that
.I f
returns a
.I real
and that
.I a
is an integer,
the calling sequence for this function would be:
.DS
.TS
lp-2w(8) l.
PUSH	\-8
RV4:\fIl	a\fR
CALL:\fIl	f\fR
POP	4
.TE
.DE
.ZP
Here we use the operator
.SM PUSH
to clear space for the return value,
load
.I a
on the stack with a ``right value'' operator,
call the function,
pop off the argument
.I a ,
and can then complete evaluation of the containing expression.
The operations used here will be explained in section 2.
.PP
If the function
.I f
were given by
.LS
 10 \*bfunction\fR f(i: integer): real;
 11 \*bbegin\fR
 12     f := i
 13 \*bend\fR;
.LE
then
.I f
would have code sequence:
.DS
.TS
lp-2w(8) l.
BEG:2	0
	11
	"f"
LV:\fIl\fR	40
RV4:\fIl\fR	32
AS48
END
.TE
.DE
.ZP
Here the
.SM BEG
operator takes 9 bytes of inline data.
The first byte specifies the 
length of the function name.
The second longword specifies the
amount of local variable storage, here none.
The succeeding two lines give the line number of the
.B begin
and the name of the block
for error traceback.
The
.SM BEG
operator places a name pointer in the block mark.
The body of the
.B function
first takes an address of the
.B function
result variable
.I f
using the address of operator
.SM LV
.I a .
The next operation in the interpretation of this function is the loading
of the value of
.I i .
.I I
is at the level of the
.B function
.I f ,
here symbolically
.I l,
and the first variable in the local variable area.
The
.B function
completes by assigning the 4 byte integer on the stack to the 8 byte
return location, hence the
.SM AS48
assignment operator, and then uses the
.SM END
operator to exit the current block.
.NH 2
The main interpreter loop
.PP
The main interpreter loop is simply:
.DS
.mD
iloop:
	\fBcaseb\fR	(lc)+,$0,$255
	<table of opcode interpreter addresses>
.DE
.ZP
The main opcode is extracted from the first byte of the instruction
and used to index into the table of opcode interpreter addresses.
Control is then transferred to the specified location.
The sub-opcode may be used to index the display,
as a small constant,
or to specify one of several relational operators.
In the cases where a constant is needed, but it
is not small enough to fit in the byte sub-operator,
a zero is placed there and the constant follows in the next word.
Zero is easily tested for,
as the instruction that fetches the
sub-opcode sets the condition code flags.
A construction like:
.DS
.mD
_OPER:
	\fBcvtbl\fR	(lc)+,r0
	\fBbneq\fR	L1
	\fBcvtwl\fR	(lc)+,r0
L1:	...
.DE
is all that is needed to effect this packing of data.
This technique saves space in the Pascal
.I obj
object code.
.PP
The address of the instruction at
.I iloop
is always contained in the register variable 
.I loop .
Thus a return to the main interpreter is simply:
.DS
	\fBjmp\fR	(loop)
.DE
that is both quick and occupies little space.
.NH 2
Errors
.PP
Errors during interpretation fall into three classes:
.DS
1) Interpreter detected errors.
2) Hardware detected errors.
3) External events.
.DE
.PP
Interpreter detected errors include I/O errors and
built-in function errors.  
These errors cause a subroutine call to an error routine
with a single parameter indicating the cause of the error.
Hardware errors such as range errors and overflows are
fielded by a special routine that determines the opcode
that caused the error.
It then calls the error routine with an appropriate error
parameter.
External events include interrupts and system limits such
as available memory.
They generate a call to the error routine with an 
appropriate error code.
The error routine processes the error condition, 
printing an appropriate error message and usually
a backtrace from the point of the error.