d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Remove paper about the Berkeley Pascal Runtime which we have never had

Browse Source 
in FreeBSD because it was VAX specific.

Approved by:	re@
This commit is contained in:
phk 2005-08-16 22:39:27 +00:00
parent a2d3a9f45d
commit 1ca93d7c74
19 changed files with 0 additions and 3129 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
share/doc/papers/Makefile
View File

@ -12,7 +12,6 @@ SUBDIR= beyond4.3 \
kerntune \
malloc \
newvm \
px \
relengr \
sysperf \
timecounter

17
share/doc/papers/px/Makefile
View File

@ -1,17 +0,0 @@
# From: @(#)Makefile 5.3 (Berkeley) 6/8/93
# $FreeBSD$
VOLUME= papers
DOC= px
SRCS= tmac.p pxin0.n pxin1.n pxin2.n pxin3.n pxin4.n
EXTRA= fig1.1.n fig1.2.n fig1.3.n fig2.3.n fig2.4.n fig3.2.n \
fig3.3.n table2.1.n table2.2.n table2.3.n table3.1.n
MACROS= -ms
USE_SOELIM=
USE_TBL=
CLEANFILES= fig2.3.n
fig2.3.n: fig2.3.raw
sort ${.ALLSRC} >${.TARGET}
.include <bsd.doc.mk>

71
share/doc/papers/px/fig1.1.n
View File

@ -1,71 +0,0 @@
.\" Copyright (c) 1979 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" @(#)fig1.1.n 5.2 (Berkeley) 4/17/91
.\"
.KF
.TS
center;
c l
l l
_ l
| l |
| cw(18) | aw(28)
| _ | l
| c | a.
Base of stack frame
Block mark Positive offsets
.sp
\(<- Display entry points here
.sp
Local
variables
.sp
_ Negative offsets
Temporary
expression
space
.sp
.T&
| _ | l
c l.
.sp
Top of stack frame
.TE
.sp
.ce
Figure 1.1 \- Structure of stack frame
.sp
.KE

68
share/doc/papers/px/fig1.2.n
View File

@ -1,68 +0,0 @@
.\" Copyright (c) 1979 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" @(#)fig1.2.n 5.2 (Berkeley) 4/17/91
.\"
.KF
.TS
center;
l l
| cw(22n) | aw(20n).
_ \&
Created by \s-2CALL\s0
Saved lino
.sp
Saved lc
.sp
Saved dp
.sp
_ \&
Created by \s-2BEG\s0
Saved dp contents
.sp
Pointer to current
entry line and
section name
.sp
Current file name
and buffer
.sp
Top of stack reference
.sp
.T&
| _ | l.
.TE
.sp
.ce
Figure 1.2 \- Block mark structure
.sp
.KE

60
share/doc/papers/px/fig1.3.n
View File

@ -1,60 +0,0 @@
.\" Copyright (c) 1979 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" @(#)fig1.3.n 5.2 (Berkeley) 4/17/91
.\"
.TS
center, allbox;
lw(20).
T{
.nf
.ce 1000
Space for
value returned
from f
.ce 0
.fi
T}
T{
.ce
Value of a
T}
T{
.sp
.ce
Block Mark
.sp
T}
.TE
.sp .1i
.ce
Figure 1.3 \- Stack structure on function call `f(a)'
.sp .1i

103
share/doc/papers/px/fig2.3.raw
View File

@ -1,103 +0,0 @@
HALT 2.2 Produce control flow backtrace
BEG s,W,w," 2.2,1.8 Write second part of block mark, enter block
END 2.2,1.8 End block execution
CALL l,A 2.2,1.8 Procedure or function call
NODUMP s,W,w," 2.2 \s-2BEG\s0 main program, suppress dump
PUSH s 2.2,1.9 Clear space (for function result)
POP s 2.2,1.9 Pop (arguments) off stack
LINO s 2.2 Set line number, count statements
TRA a 2.2 Short control transfer (local branching)
TRA4 A 2.2 Long control transfer
GOTO l,A 2.2,1.8 Non-local goto statement
IF a 2.3 Conditional transfer
REL* r 2.3 Relational test yielding Boolean result
AND 2.4 Boolean and
OR 2.4 Boolean or
NOT 2.4 Boolean not
LRV* l,A 2.5 Right value (load) operators
RV* l,a 2.5 Right value (load) operators
CON* v 2.5 Load constant operators
AS* 2.5 Assignment operators
OFF s 2.5 Offset address, typically used for field reference
INX* s,w,w 2.6 Subscripting (indexing) operator
NIL 2.6 Assert non-nil pointer
LLV l,W 2.6 Address of operator
LV l,w 2.6 Address of operator
IND* 2.6 Indirection operators
ADD* 2.7 Addition
SUB* 2.7 Subtraction
MUL* 2.7 Multiplication
SQR* 2.7 Squaring
DIV* 2.7 Fixed division
MOD* 2.7 Modulus
ABS* 2.7 Absolute value
NEG* 2.7 Negation
DVD* 2.7 Floating division
RANG* v 2.8 Subrange checking
CASEOP* 2.9 Case statements
FOR* a 2.12 For statements
PXPBUF w 2.10 Initialize \fIpxp\fP count buffer
TRACNT w,A 2.10 Count a procedure entry
COUNT w 2.10 Count a statement count point
CTTOT s,w,w 2.11 Construct set
CARD s 2.11 Cardinality of set
STOI 2.12 Convert short to long integer
STOD 2.12 Convert short integer to real
ITOD 2.12 Convert integer to real
ITOS 2.12 Convert integer to short integer
GET 3.7 Get next record from a file
PUT 3.8 Output a record to a file
MESSAGE 3.6 Write to terminal
FNIL 3.7 Check file initialized, not eof, synced
FLUSH 3.11 Flush a file
BUFF 3.11 Specify buffering for file "output"
EOF 3.10 Returns \fItrue\fR if end of file
EOLN 3.10 Returns \fItrue\fR if end of line on input text file
RESET 3.11 Open file for input
REWRITE 3.11 Open file for output
REMOVE 3.11 Remove a file
UNIT* 3.10 Set active file
READ* 3.7 Read a record from a file
WRITEC 3.8 Character unformatted write
WRITEF l 3.8 General formatted write
WRITES l 3.8 String unformatted write
WRITLN 3.8 Output a newline to a text file
PAGE 3.8 Output a formfeed to a text file
MIN s 3.8 Minimum of top of stack and \fIs\fR
MAX s,w 3.8 Maximum of top of stack and \fIw\fR
NAM A 3.8 Convert enumerated type value to print format
FILE 3.9 Push descriptor for active file
DEFNAME 3.11 Attach file name for \fBprogram\fR statement files
PACK s,w,w,w 2.15 Convert and copy from unpacked to packed
UNPACK s,w,w,w 2.15 Convert and copy from packed to unpacked
LLIMIT 2.14 Set linelimit for output text file
ARGC 2.14 Returns number of arguments to current process
ARGV 2.14 Copy specified process argument into char array
CLCK 2.14 Returns user time of program
SCLCK 2.14 Returns system time of program
WCLCK 2.14 Returns current time stamp
DATE 2.14 Copy date into char array
TIME 2.14 Copy time into char array
SEED 2.13 Set random seed, return old seed
RANDOM 2.13 Returns random number
DISPOSE 2.15 Dispose of a heap allocation
NEW s 2.15 Allocate a record on heap, set pointer to it
EXPO 2.13 Returns machine representation of real exponent
ATAN 2.13 Returns arctangent of argument
EXP 2.13 Returns exponential of argument
LN 2.13 Returns natural log of argument
COS 2.13 Returns cos of argument
SIN 2.13 Returns sin of argument
SQRT 2.13 Returns square root of argument
CHR* 2.15 Returns integer to ascii mapping of argument
ODD* 2.15 Returns \fItrue\fR if argument is odd, \fIfalse\fR if even
PRED* 2.7 Returns predecessor of argument
STLIM 2.14 Set program statement limit
SUCC* 2.7 Returns successor of argument
ROUND 2.13 Returns \s-2TRUNC\s0(argument + 0.5)
TRUNC 2.13 Returns integer part of argument
UNDEF 2.15 Returns \fIfalse\fR
SDUP 2.2 Duplicate top stack word
ASRT 2.12 Assert \fItrue\fR to continue
IN s,w,w 2.11 Set membership
INCT 2.11 Membership in a constructed set

57
share/doc/papers/px/fig2.4.n
View File

@ -1,57 +0,0 @@
.\" Copyright (c) 1979 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" @(#)fig2.4.n 5.2 (Berkeley) 4/17/91
.\"
.KF
.TS
center, box;
cw(15).
\s-2CASEOP\s0
_
No. of cases
_
.sp
Case
transfer
table
.sp
_
.sp
Array of case
label values
.sp
.TE
.sp
.ce
Figure 2.4 \- Case data structure
.sp
.KE

57
share/doc/papers/px/fig3.2.n
View File

@ -1,57 +0,0 @@
.\" Copyright (c) 1979 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" @(#)fig3.2.n 5.2 (Berkeley) 4/17/91
.\" $FreeBSD$
.\"
.KF
.TS
center, box;
cw(15).
No. of cases
_
.sp
offsets
of element
names
.sp
_
.sp
Array of
null terminated
element names
.sp
.TE
.sp
.ce
Figure 3.2 \- Enumerated type conversion structure
.sp
.KE

57
share/doc/papers/px/fig3.3.n
View File

@ -1,57 +0,0 @@
.\" Copyright (c) 1979 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" @(#)fig3.3.n 5.2 (Berkeley) 4/17/91
.\"
.KF
.TS
center;
l l
l | cw(15) |.
_
\fIbool\fP: 2
_
6
_
12
_
17
_
"false"
_
"true"
_
.TE
.sp
.ce
Figure 3.3 \- Boolean type conversion structure
.sp
.KE

140
share/doc/papers/px/pxin0.n
View File

@ -1,140 +0,0 @@
.\" Copyright (c) 1979 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" @(#)pxin0.n 5.2 (Berkeley) 4/17/91
.\" $FreeBSD$
.\"
.RP
.TL
Berkeley Pascal
PX Implementation Notes
.br
Version 2.0 \- January, 1979
.AU
William N. Joy\*(Dg
.AU
M. Kirk McKusick\*(Dd
.AI
Computer Science Division
Department of Electrical Engineering and Computer Science
University of California, Berkeley
Berkeley, California 94720
.AB
.PP
Berkeley Pascal
is designed for interactive instructional use and runs on the
.SM "VAX 11/780" .
The interpreter
.I px
executes the Pascal binaries generated by the Pascal translator
.I pi .
.PP
The
.I
PX Implementation Notes
.R
describe the general organization of
.I px ,
detail the various operations of the interpreter,
and describe the file input/output structure.
Conclusions are given on the viability of an interpreter
based approach to language implementation for an instructional environment.
.AE
.if n 'ND
.SH
Introduction
.PP
These
.I
PX Implementation Notes
.R
have been updated from the original
.SM "PDP 11/70"
implementation notes to reflect the interpreter that runs on the
.SM "VAX 11/780" .
These notes consist of four major parts.
The first part outlines the general organization of
.I px .
Section 2 describes the operations (instructions) of the interpreter
while section 3 focuses on input/output related activity.
A final section gives conclusions about the viability of an interpreter
based approach to language implementation for instruction.
.SH
Related Berkeley Pascal documents
.PP
The
.I "PXP Implementation Notes"
give details of the internals of the execution profiler
.I pxp;
parts of the interpreter related to
.I pxp
are discussed in section 2.10.
A paper describing the syntactic error recovery mechanism used in
.I pi
was presented at the ACM Conference on Compiler Construction
in Boulder Colorado in August, 1979.
.SH
Acknowledgements
.PP
This version of
.I px
is a
.SM "PDP 11/70"
to
.SM "VAX 11/780"
opcode mapping of the original
.I px
that was designed and implemented by Ken Thompson,
with extensive modifications and additions
by William Joy
and Charles Haley.
Without their work, this
.UP
system would never have existed.
These notes were first written by William Joy for the
.SM "PDP 11/70"
implementation.
We would also like to thank our faculty advisor Susan L. Graham
for her encouragement,
her helpful comments and suggestions
relating to
.UP
and her excellent editorial assistance.
.FS
\*(dg\ The financial support of the National Science Foundation under grants
MCS74-07644-A03 and MCS78-07291
and of an \s-2IBM\s0 Graduate Fellowship are gratefully acknowledged.
.FE
.FS
\*(dd\ The financial support of a Howard Hughes Graduate
Fellowship is gratefully acknowledged.
.FE
.bp

538
share/doc/papers/px/pxin1.n
View File

@ -1,538 +0,0 @@
.\" Copyright (c) 1979 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" @(#)pxin1.n 5.2 (Berkeley) 4/17/91
.\" $FreeBSD$
.\"
.tr _\(ru
.nr H1 0
.NH
Organization
.PP
Most of
.I px
is written in the
.SM "VAX 11/780"
assembly language, using the
.UX
assembler
.I as.
Portions of
.I px
are also written in the
.UX
systems programming language C.
.I Px
consists of a main procedure that reads in the interpreter code,
a main interpreter loop that transfers successively to various
code segments implementing the abstract machine operations,
built-in procedures and functions,
and several routines that support the implementation of the
Pascal input-output environment.
.PP
The interpreter runs at a fraction of the speed of equivalent
compiled C code, with this fraction varying from 1/5 to 1/15.
The interpreter occupies 18.5K bytes of instruction space, shared among
all processes executing Pascal, and has 4.6K bytes of data space (constants,
error messages, etc.) a copy of which is allocated to each executing process.
.NH 2
Format of the object file
.PP
.I Px
normally interprets the code left in an object file by a run of the
Pascal translator
.I pi.
The file where the translator puts the object originally, and the most
commonly interpreted file, is called
.I obj.
In order that all persons using
.I px
share a common text image, this executable file is
a small process that coordinates with the interpreter to start
execution.
The interpreter code is placed
at the end of a special ``header'' file and the size of the initialized
data area of this header file is expanded to include this code,
so that during execution it is located at an
easily determined address in its data space.
When executed, the object process creates a
.I pipe ,
creates another process by doing a
.I fork ,
and arranges that the resulting parent process becomes an instance of
.I px .
The child process then writes the interpreter code through
the pipe that it has to the
interpreter process parent.
When this process is complete, the child exits.
.PP
The real advantage of this approach is that it does not require modifications
to the shell, and that the resultant objects are ``true objects'' not
requiring special treatment.
A simpler mechanism would be to determine the name of the file that was
executed and pass this to the interpreter.
However it is not possible to determine this name
in all cases.\*(Dd
.FS
\*(dd\ For instance, if the
.I pxref
program is placed in the directory
`/usr/bin'
then when the user types
``pxref program.p''
the first argument to the program, nominally the programs name, is
``pxref.''
While it would be possible to search in the standard place,
i.e. the current directory, and the system directories
`/bin'
and
`/usr/bin'
for a corresponding object file,
this would be expensive and not guaranteed to succeed.
Several shells exist that allow other directories to be searched
for commands, and there is,
in general,
no way to determine what these directories are.
.FE
.NH 2
General features of object code
.PP
Pascal object code is relocatable as all addressing references for
control transfers within the code are relative.
The code consists of instructions interspersed with inline data.
All instructions have a length that is an even number of bytes.
No variables are kept in the object code area.
.PP
The first byte of a Pascal interpreter instruction contains an operation
code.
This allows a total of 256 major operation codes, and 232 of these are
in use in the current
.I px.
The second byte of each interpreter instruction is called the
``sub-operation code'',
or more commonly the
.I sub-opcode.
It contains a small integer that may, for example, be used as a
block-structure level for the associated operation.
If the instruction can take a longword constant,
this constant is often packed into the sub-opcode
if it fits into 8 bits and is not zero.
A sub-opcode value of zero specifies that the constant would not
fit and therefore follows in the next word.
This is a space optimization, the value of zero for flagging
the longer case being convenient because it is easy to test.
.PP
Other instruction formats are used.
The branching
instructions take an offset in the following word,
operators that load constants onto the stack
take arbitrarily long inline constant values,
and many operations deal exclusively with data on the
interpreter stack, requiring no inline data.
.NH 2
Stack structure of the interpreter
.PP
The interpreter emulates a stack-structured Pascal machine.
The ``load'' instructions put values onto the stack, where all
arithmetic operations take place.
The ``store'' instructions take values off the stack
and place them in an address that is also contained on the stack.
The only way to move data or to compute in the machine is with the stack.
.PP
To make the interpreter operations more powerful
and to thereby increase the interpreter speed,
the arithmetic operations in the interpreter are ``typed''.
That is, length conversion of arithmetic values occurs when they are
used in an operation.
This eliminates interpreter cycles for length conversion
and the associated overhead.
For example, when adding an integer that fits in one byte to one that
requires four bytes to store, no ``conversion'' operators are required.
The one byte integer is loaded onto the stack, followed by the four
byte integer, and then an adding operator is used that has, implicit
in its definition, the sizes of the arguments.
.NH 2
Data types in the interpreter
.PP
The interpreter deals with several different fundamental data types.
In the memory of the machine, 1, 2, and 4 byte integers are supported,
with only 2 and 4 byte integers being present on the stack.
The interpreter always converts to 4 byte integers when there is a possibility
of overflowing the shorter formats.
This corresponds to the Pascal language definition of overflow in
arithmetic operations that requires that the result be correct
if all partial values lie within the bounds of the base integer type:
4 byte integer values.
.PP
Character constants are treated similarly to 1 byte integers for
most purposes, as are Boolean values.
All enumerated types are treated as integer values of
an appropriate length, usually 1 byte.
The interpreter also has real numbers, occupying 8 bytes of storage,
and sets and strings of varying length.
The appropriate operations are included for each data type, such as
set union and intersection and an operation to write a string.
.PP
No special
.B packed
data formats are supported by the interpreter.
The smallest unit of storage occupied by any variable is one byte.
The built-ins
.I pack
and
.I unpack
thus degenerate to simple memory to memory transfers with
no special processing.
.NH 2
Runtime environment
.PP
The interpreter runtime environment uses a stack data area and a heap
data area, that are kept at opposite ends of memory
and grow towards each other.
All global variables and variables local to procedures and functions
are kept in the stack area.
Dynamically allocated variables and buffers for input/output are
allocated in the heap.
.PP
The addressing of block structured variables is done by using
a fixed display
that contains the address of its stack frame
for each statically active block.\*(Dg
.FS
\*(dg\ Here ``block'' is being used to mean any
.I procedure ,
.I function
or the main program.
.FE
This display is referenced by instructions that load and store
variables and maintained by the operations for
block entry and exit, and for non-local
.B goto
statements.
.NH 2
Dp, lc, loop
.PP
Three ``global'' variables in the interpreter, in addition to the
``display'', are the
.I dp,
.I lc,
and the
.I loop.
The
.I dp
is a pointer to the display entry for the current block;
the
.I lc
is the abstract machine location counter;
and the
.I loop
is a register that holds the address of the main interpreter
loop so that returning to the loop to fetch the next instruction is
a fast operation.
.NH 2
The stack frame structure
.PP
Each active block
has a stack frame consisting of three parts:
a block mark, local variables, and temporary storage for partially
evaluated expressions.
The stack in the interpreter grows from the high addresses in memory
to the low addresses,
so that those parts of the stack frame that are ``on the top''
of the stack have the most negative offsets from the display
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.

923
share/doc/papers/px/pxin2.n
View File

@ -1,923 +0,0 @@
.\" Copyright (c) 1979 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" @(#)pxin2.n 5.2 (Berkeley) 4/17/91
.\" $FreeBSD$
.\"
.nr H1 1
.if n .ND
.NH
Operations
.NH 2
Naming conventions and operation summary
.PP
Table 2.1 outlines the opcode typing convention.
The expression ``a above b'' means that `a' is on top
of the stack with `b' below it.
Table 2.3 describes each of the opcodes.
The character `*' at the end of a name specifies that
all operations with the root prefix
before the `*'
are summarized by one entry.
Table 2.2 gives the codes used
to describe the type inline data expected by each instruction.
.sp 2
.so table2.1.n
.sp 2
.so table2.2.n
.bp
.so table2.3.n
.bp
.NH 2
Basic control operations
.LP
.SH
HALT
.IP
Corresponds to the Pascal procedure
.I halt ;
causes execution to end with a post-mortem backtrace as if a run-time
error had occurred.
.SH
BEG s,W,w,"
.IP
Causes the second part of the block mark to be created, and
.I W
bytes of local variable space to be allocated and cleared to zero.
Stack overflow is detected here.
.I w
is the first line of the body of this section for error traceback,
and the inline string (length s) the character representation of its name.
.SH
NODUMP s,W,w,"
.IP
Equivalent to
.SM BEG ,
and used to begin the main program when the ``p''
option is disabled so that the post-mortem backtrace will be inhibited.
.SH
END
.IP
Complementary to the operators
.SM CALL
and
.SM BEG ,
exits the current block, calling the procedure
.I pclose
to flush buffers for and release any local files.
Restores the environment of the caller from the block mark.
If this is the end for the main program, all files are
.I flushed,
and the interpreter is exited.
.SH
CALL l,A
.IP
Saves the current line number, return address, and active display entry pointer
.I dp
in the first part of the block mark, then transfers to the entry point
given by the relative address
.I A ,
that is the beginning of a
.B procedure
or
.B function
at level
.I l.
.SH
PUSH s
.IP
Clears
.I s
bytes on the stack.
Used to make space for the return value of a
.B function
just before calling it.
.SH
POP s
.IP
Pop
.I s
bytes off the stack.
Used after a
.B function
or
.B procedure
returns to remove the arguments from the stack.
.SH
TRA a
.IP
Transfer control to relative address
.I a
as a local
.B goto
or part of a structured statement.
.SH
TRA4 A
.IP
Transfer control to an absolute address as part of a non-local
.B goto
or to branch over procedure bodies.
.SH
LINO s
.IP
Set current line number to
.I s.
For consistency, check that the expression stack is empty
as it should be (as this is the start of a statement.)
This consistency check will fail only if there is a bug in the
interpreter or the interpreter code has somehow been damaged.
Increment the statement count and if it exceeds the statement limit,
generate a fault.
.SH
GOTO l,A
.IP
Transfer control to address
.I A
that is in the block at level
.I l
of the display.
This is a non-local
.B goto.
Causes each block to be exited as if with
.SM END ,
flushing and freeing files with
.I pclose,
until the current display entry is at level
.I l.
.SH
SDUP*
.IP
Duplicate the word or long on the top of
the stack.
This is used mostly for constructing sets.
See section 2.11.
.NH 2
If and relational operators
.SH
IF a
.IP
The interpreter conditional transfers all take place using this operator
that examines the Boolean value on the top of the stack.
If the value is
.I true ,
the next code is executed,
otherwise control transfers to the specified address.
.SH
REL* r
.IP
These take two arguments on the stack,
and the sub-operation code specifies the relational operation to
be done, coded as follows with `a' above `b' on the stack:
.DS
.mD
.TS
lb lb
c a.
Code Operation
_
0 a = b
2 a <> b
4 a < b
6 a > b
8 a <= b
10 a >= b
.TE
.DE
.IP
Each operation does a test to set the condition code
appropriately and then does an indexed branch based on the
sub-operation code to a test of the condition here specified,
pushing a Boolean value on the stack.
.IP
Consider the statement fragment:
.DS
.mD
\*bif\fR a = b \*bthen\fR
.DE
.IP
If
.I a
and
.I b
are integers this generates the following code:
.DS
.TS
lp-2w(8) l.
RV4:\fIl a\fR
RV4:\fIl b\fR
REL4 \&=
IF \fIElse part offset\fR
.sp
.T&
c s.
\fI\&... Then part code ...\fR
.TE
.DE
.NH 2
Boolean operators
.PP
The Boolean operators
.SM AND ,
.SM OR ,
and
.SM NOT
manipulate values on the top of the stack.
All Boolean values are kept in single bytes in memory,
or in single words on the stack.
Zero represents a Boolean \fIfalse\fP, and one a Boolean \fItrue\fP.
.NH 2
Right value, constant, and assignment operators
.SH
LRV* l,A
.br
RV* l,a
.IP
The right value operators load values on the stack.
They take a block number as a sub-opcode and load the appropriate
number of bytes from that block at the offset specified
in the following word onto the stack. As an example, consider
.SM LRV4 :
.DS
.mD
_LRV4:
\fBcvtbl\fR (lc)+,r0 #r0 has display index
\fBaddl3\fR _display(r0),(lc)+,r1 #r1 has variable address
\fBpushl\fR (r1) #put value on the stack
\fBjmp\fR (loop)
.DE
.IP
Here the interpreter places the display level in r0.
It then adds the appropriate display value to the inline offset and
pushes the value at this location onto the stack.
Control then returns to the main
interpreter loop.
The
.SM RV*
operators have short inline data that
reduces the space required to address the first 32K of
stack space in each stack frame.
The operators
.SM RV14
and
.SM RV24
provide explicit conversion to long as the data
is pushed.
This saves the generation of
.SM STOI
to align arguments to
.SM C
subroutines.
.SH
CON* r
.IP
The constant operators load a value onto the stack from inline code.
Small integer values are condensed and loaded by the
.SM CON1
operator, that is given by
.DS
.mD
_CON1:
\fBcvtbw\fR (lc)+,\-(sp)
\fBjmp\fR (loop)
.DE
.IP
Here note that little work was required as the required constant
was available at (lc)+.
For longer constants,
.I lc
must be incremented before moving the constant.
The operator
.SM CON
takes a length specification in the sub-opcode and can be used to load
strings and other variable length data onto the stack.
The operators
.SM CON14
and
.SM CON24
provide explicit conversion to long as the constant is pushed.
.SH
AS*
.IP
The assignment operators are similar to arithmetic and relational operators
in that they take two operands, both in the stack,
but the lengths given for them specify
first the length of the value on the stack and then the length
of the target in memory.
The target address in memory is under the value to be stored.
Thus the statement
.DS
i := 1
.DE
.IP
where
.I i
is a full-length, 4 byte, integer,
will generate the code sequence
.DS
.TS
lp-2w(8) l.
LV:\fIl i\fP
CON1:1
AS24
.TE
.DE
.IP
Here
.SM LV
will load the address of
.I i,
that is really given as a block number in the sub-opcode and an
offset in the following word,
onto the stack, occupying a single word.
.SM CON1 ,
that is a single word instruction,
then loads the constant 1,
that is in its sub-opcode,
onto the stack.
Since there are not one byte constants on the stack,
this becomes a 2 byte, single word integer.
The interpreter then assigns a length 2 integer to a length 4 integer using
.SM AS24 \&.
The code sequence for
.SM AS24
is given by:
.DS
.mD
_AS24:
\fBincl\fR lc
\fBcvtwl\fR (sp)+,*(sp)+
\fBjmp\fR (loop)
.DE
.IP
Thus the interpreter gets the single word off the stack,
extends it to be a 4 byte integer
gets the target address off the stack,
and finally stores the value in the target.
This is a typical use of the constant and assignment operators.
.NH 2
Addressing operations
.SH
LLV l,W
.br
LV l,w
.IP
The most common operation done by the interpreter
is the ``left value'' or ``address of'' operation.
It is given by:
.DS
.mD
_LLV:
\fBcvtbl\fR (lc)+,r0 #r0 has display index
\fBaddl3\fR _display(r0),(lc)+,\-(sp) #push address onto the stack
\fBjmp\fR (loop)
.DE
.IP
It calculates an address in the block specified in the sub-opcode
by adding the associated display entry to the
offset that appears in the following word.
The
.SM LV
operator has a short inline data that reduces the space
required to address the first 32K of stack space in each call frame.
.SH
OFF s
.IP
The offset operator is used in field names.
Thus to get the address of
.LS
p^.f1
.LE
.IP
.I pi
would generate the sequence
.DS
.mD
.TS
lp-2w(8) l.
RV:\fIl p\fP
OFF \fIf1\fP
.TE
.DE
.IP
where the
.SM RV
loads the value of
.I p,
given its block in the sub-opcode and offset in the following word,
and the interpreter then adds the offset of the field
.I f1
in its record to get the correct address.
.SM OFF
takes its argument in the sub-opcode if it is small enough.
.SH
NIL
.IP
The example above is incomplete, lacking a check for a
.B nil
pointer.
The code generated would be
.DS
.TS
lp-2w(8) l.
RV:\fIl p\fP
NIL
OFF \fIf1\fP
.TE
.DE
.IP
where the
.SM NIL
operation checks for a
.I nil
pointer and generates the appropriate runtime error if it is.
.SH
LVCON s,"
.IP
A pointer to the specified length inline data is pushed
onto the stack.
This is primarily used for
.I printf
type strings used by
.SM WRITEF .
(see sections 3.6 and 3.8)
.SH
INX* s,w,w
.IP
The operators
.SM INX2
and
.SM INX4
are used for subscripting.
For example, the statement
.DS
a[i] := 2.0
.DE
.IP
with
.I i
an integer and
.I a
an
``array [1..1000] of real''
would generate
.DS
.TS
lp-2w(8) l.
LV:\fIl a\fP
RV4:\fIl i\fP
INX4:8 1,999
CON8 2.0
AS8
.TE
.DE
.IP
Here the
.SM LV
operation takes the address of
.I a
and places it on the stack.
The value of
.I i
is then placed on top of this on the stack.
The array address is indexed by the
length 4 index (a length 2 index would use
.SM INX2 )
where the individual elements have a size of 8 bytes.
The code for
.SM INX4
is:
.DS
.mD
_INX4:
\fBcvtbl\fR (lc)+,r0
\fBbneq\fR L1
\fBcvtwl\fR (lc)+,r0 #r0 has size of records
L1:
\fBcvtwl\fR (lc)+,r1 #r1 has lower bound
\fBmovzwl\fR (lc)+,r2 #r2 has upper-lower bound
\fBsubl3\fR r1,(sp)+,r3 #r3 has base subscript
\fBcmpl\fR r3,r2 #check for out of bounds
\fBbgtru\fR esubscr
\fBmull2\fR r0,r3 #calculate byte offset
\fBaddl2\fR r3,(sp) #calculate actual address
\fBjmp\fR (loop)
esubscr:
\fBmovw\fR $ESUBSCR,_perrno
\fBjbr\fR error
.DE
.IP
Here the lower bound is subtracted, and range checked against the
upper minus lower bound.
The offset is then scaled to a byte offset into the array
and added to the base address on the stack.
Multi-dimension subscripts are translated as a sequence of single subscriptings.
.SH
IND*
.IP
For indirect references through
.B var
parameters and pointers,
the interpreter has a set of indirection operators that convert a pointer
on the stack into a value on the stack from that address.
different
.SM IND
operators are necessary because of the possibility of different
length operands.
The
.SM IND14
and
.SM IND24
operators do conversions to long
as they push their data.
.NH 2
Arithmetic operators
.PP
The interpreter has many arithmetic operators.
All operators produce results long enough to prevent overflow
unless the bounds of the base type are exceeded.
The basic operators available are
.DS
Addition: ADD*, SUCC*
Subtraction: SUB*, PRED*
Multiplication: MUL*, SQR*
Division: DIV*, DVD*, MOD*
Unary: NEG*, ABS*
.DE
.NH 2
Range checking
.PP
The interpreter has several range checking operators.
The important distinction among these operators is between values whose
legal range begins at zero and those that do not begin at zero,
for example
a subrange variable whose values range from 45 to 70.
For those that begin at zero, a simpler ``logical'' comparison against
the upper bound suffices.
For others, both the low and upper bounds must be checked independently,
requiring two comparisons.
On the
.SM "VAX 11/780"
both checks are done using a single index instruction
so the only gain is in reducing the inline data.
.NH 2
Case operators
.PP
The interpreter includes three operators for
.B case
statements that are used depending on the width of the
.B case
label type.
For each width, the structure of the case data is the same, and
is represented in figure 2.4.
.sp 1
.so fig2.4.n
.PP
The
.SM CASEOP
case statement operators do a sequential search through the
case label values.
If they find the label value, they take the corresponding entry
from the transfer table and cause the interpreter to branch to the
specified statement.
If the specified label is not found, an error results.
.PP
The
.SM CASE
operators take the number of cases as a sub-opcode
if possible.
Three different operators are needed to handle single byte,
word, and long case transfer table values.
For example, the
.SM CASEOP1
operator has the following code sequence:
.DS
.mD
_CASEOP1:
\fBcvtbl\fR (lc)+,r0
\fBbneq\fR L1
\fBcvtwl\fR (lc)+,r0 #r0 has length of case table
L1:
\fBmovaw\fR (lc)[r0],r2 #r2 has pointer to case labels
\fBmovzwl\fR (sp)+,r3 #r3 has the element to find
\fBlocc\fR r3,r0,(r2) #r0 has index of located element
\fBbeql\fR caserr #element not found
\fBmnegl\fR r0,r0 #calculate new lc
\fBcvtwl\fR (r2)[r0],r1 #r1 has lc offset
\fBaddl2\fR r1,lc
\fBjmp\fR (loop)
caserr:
\fBmovw\fR $ECASE,_perrno
\fBjbr\fR error
.DE
.PP
Here the interpreter first computes the address of the beginning
of the case label value area by adding twice the number of case label
values to the address of the transfer table, since the transfer
table entries are 2 byte address offsets.
It then searches through the label values, and generates an ECASE
error if the label is not found.
If the label is found, the index of the corresponding entry
in the transfer table is extracted and that offset is added
to the interpreter location counter.
.NH 2
Operations supporting pxp
.PP
The following operations are defined to do execution profiling.
.SH
PXPBUF w
.IP
Causes the interpreter to allocate a count buffer
with
.I w
four byte counters
and to clear them to zero.
The count buffer is placed within an image of the
.I pmon.out
file as described in the
.I "PXP Implementation Notes."
The contents of this buffer are written to the file
.I pmon.out
when the program ends.
.SH
COUNT w
.IP
Increments the counter specified by
.I w .
.SH
TRACNT w,A
.IP
Used at the entry point to procedures and functions,
combining a transfer to the entry point of the block with
an incrementing of its entry count.
.NH 2
Set operations
.PP
The set operations:
union
.SM ADDT,
intersection
.SM MULT,
element removal
.SM SUBT,
and the set relationals
.SM RELT
are straightforward.
The following operations are more interesting.
.SH
CARD s
.IP
Takes the cardinality of a set of size
.I s
bytes on top of the stack, leaving a 2 byte integer count.
.SM CARD
uses the
.B ffs
opcode to successively count the number of set bits in the set.
.SH
CTTOT s,w,w
.IP
Constructs a set.
This operation requires a non-trivial amount of work,
checking bounds and setting individual bits or ranges of bits.
This operation sequence is slow,
and motivates the presence of the operator
.SM INCT
below.
The arguments to
.SM CTTOT
include the number of elements
.I s
in the constructed set,
the lower and upper bounds of the set,
the two
.I w
values,
and a pair of values on the stack for each range in the set, single
elements in constructed sets being duplicated with
.SM SDUP
to form degenerate ranges.
.SH
IN s,w,w
.IP
The operator
.B in
for sets.
The value
.I s
specifies the size of the set,
the two
.I w
values the lower and upper bounds of the set.
The value on the stack is checked to be in the set on the stack,
and a Boolean value of
.I true
or
.I false
replaces the operands.
.SH
INCT
.IP
The operator
.B in
on a constructed set without constructing it.
The left operand of
.B in
is on top of the stack followed by the number of pairs in the
constructed set,
and then the pairs themselves, all as single word integers.
Pairs designate runs of values and single values are represented by
a degenerate pair with both value equal.
This operator is generated in grammatical constructs such as
.LS
\fBif\fR character \fBin\fR [`+', '\-', `*', `/']
.LE
.IP
or
.LS
\fBif\fR character \fBin\fR [`a'..`z', `$', `_']
.LE
.IP
These constructs are common in Pascal, and
.SM INCT
makes them run much faster in the interpreter,
as if they were written as an efficient series of
.B if
statements.
.NH 2
Miscellaneous
.PP
Other miscellaneous operators that are present in the interpreter
are
.SM ASRT
that causes the program to end if the Boolean value on the stack is not
.I true,
and
.SM STOI ,
.SM STOD ,
.SM ITOD ,
and
.SM ITOS
that convert between different length arithmetic operands for
use in aligning the arguments in
.B procedure
and
.B function
calls, and with some untyped built-ins, such as
.SM SIN
and
.SM COS \&.
.PP
Finally, if the program is run with the run-time testing disabled, there
are special operators for
.B for
statements
and special indexing operators for arrays
that have individual element size that is a power of 2.
The code can run significantly faster using these operators.
.NH 2
Mathematical Functions
.PP
The transcendental functions
.SM SIN ,
.SM COS ,
.SM ATAN ,
.SM EXP ,
.SM LN ,
.SM SQRT ,
.SM SEED ,
and
.SM RANDOM
are taken from the standard UNIX
mathematical package.
These functions take double precision floating point
values and return the same.
.PP
The functions
.SM EXPO ,
.SM TRUNC ,
and
.SM ROUND
take a double precision floating point number.
.SM EXPO
returns an integer representing the machine
representation of its argument's exponent,
.SM TRUNC
returns the integer part of its argument, and
.SM ROUND
returns the rounded integer part of its argument.
.NH 2
System functions and procedures
.SH
LLIMIT
.IP
A line limit and a file pointer are passed on the stack.
If the limit is non-negative the line limit is set to the
specified value, otherwise it is set to unlimited.
The default is unlimited.
.SH
STLIM
.IP
A statement limit is passed on the stack. The statement limit
is set as specified.
The default is 500,000.
No limit is enforced when the ``p'' option is disabled.
.SH
CLCK
.br
SCLCK
.IP
.SM CLCK
returns the number of milliseconds of user time used by the program;
.SM SCLCK
returns the number of milliseconds of system time used by the program.
.SH
WCLCK
.IP
The number of seconds since some predefined time is
returned. Its primary usefulness is in determining
elapsed time and in providing a unique time stamp.
.sp
.LP
The other system time procedures are
.SM DATE
and
.SM TIME
that copy an appropriate text string into a pascal string array.
The function
.SM ARGC
returns the number of command line arguments passed to the program.
The procedure
.SM ARGV
takes an index on the stack and copies the specified
command line argument into a pascal string array.
.NH 2
Pascal procedures and functions
.SH
PACK s,w,w,w
.br
UNPACK s,w,w,w
.IP
They function as a memory to memory move with several
semantic checks.
They do no ``unpacking'' or ``packing'' in the true sense as the
interpreter supports no packed data types.
.SH
NEW s
.br
DISPOSE s
.IP
An
.SM LV
of a pointer is passed.
.SM NEW
allocates a record of a specified size and puts a pointer
to it into the pointer variable.
.SM DISPOSE
deallocates the record pointed to by the pointer
and sets the pointer to
.SM NIL .
.sp
.LP
The function
.SM CHR*
converts a suitably small integer into an ascii character.
Its primary purpose is to do a range check.
The function
.SM ODD*
returns
.I true
if its argument is odd and returns
.I false
if its argument is even.
The function
.SM UNDEF
always returns the value
.I false .

597
share/doc/papers/px/pxin3.n
View File

@ -1,597 +0,0 @@
.\" Copyright (c) 1979 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" @(#)pxin3.n 5.2 (Berkeley) 4/17/91
.\" $FreeBSD$
.\"
.ta 8n 16n 24n
.nr H1 2
.if n .ND
.NH
Input/output
.NH 2
The files structure
.PP
Each file in the Pascal environment is represented by a pointer
to a
.I files
structure in the heap.
At the location addressed by the pointer is the element
in the file's window variable.
Behind this window variable is information about the file,
at the following offsets:
.so table3.1.n
.PP
Here
.SM FBUF
is a pointer to the system FILE block for the file.
The standard system I/O library is
used that provides block buffered input/output,
with 1024 characters normally transferred at each read or write.
.PP
The files in the
Pascal environment,
are all linked together on a single file chain through the
.SM FCHAIN
links.
For each file the
.SM FLEV
pointer gives its associated file variable.
These are used to free files at block exit as described in section 3.3
below.
.PP
The
FNAME
and
PFNAME
give the associated
file name for the file and the name to be used when printing
error diagnostics respectively.
Although these names are usually the same,
.I input
and
.I output
usually have no associated
file name so the distinction is necessary.
.PP
The
FUNIT
word contains
a set of flags.
whose representations are:
.TS
center;
l l l.
EOF 0x0100 At end-of-file
EOLN 0x0200 At end-of-line (text files only)
SYNC 0x0400 File window is out of sync
TEMP 0x0800 File is temporary
FREAD 0x1000 File is open for reading
FWRITE 0x2000 File is open for writing
FTEXT 0x4000 File is a text file; process EOLN
FDEF 0x8000 File structure created, but file not opened
.TE
.PP
The
EOF
and
EOLN
bits here reflect the associated built-in function values.
TEMP
specifies that the file has a generated temporary name and that
it should therefore be removed when its block exits.
FREAD
and
FWRITE
specify that
.I reset
and
.I rewrite
respectively have been done on the file so that
input or output operations can be done.
FTEXT
specifies the file is a text file so that
EOLN
processing should be done,
with newline characters turned into blanks, etc.
.PP
The
SYNC
bit,
when true,
specifies that there is no usable image in the file buffer window.
As discussed in the
.I "Berkeley Pascal User's Manual,"
the interactive environment necessitates having
``input^'' undefined at the beginning
of execution so that a program may print a prompt
before the user is required to type input.
The
SYNC
bit implements this.
When it is set,
it specifies that the element in the window
must be updated before it can be used.
This is never done until necessary.
.NH 2
Initialization of files
.PP
All the variables in the Pascal runtime environment are cleared to zero on
block entry.
This is necessary for simple processing of files.
If a file is unused, its pointer will be
.B nil.
All references to an inactive file are thus references through a
.B nil
pointer.
If the Pascal system did not clear storage to zero before execution
it would not be possible to detect inactive files in this simple way;
it would probably be necessary to generate (possibly complicated)
code to initialize
each file on block entry.
.PP
When a file is first mentioned in a
.I reset
or
.I rewrite
call,
a buffer of the form described above is associated with it,
and the necessary information about the file is placed in this
buffer.
The file is also linked into the active file chain.
This chain is kept sorted by block mark address, the
FLEV
entries.
.NH 2
Block exit
.PP
When block exit occurs the interpreter must free the files that are in
use in the block
and their associated buffers.
This is simple and efficient because the files in the active file chain are
sorted by increasing block mark address.
This means that the files for the current block will be at the front
of the chain.
For each file that is no longer accessible
the interpreter first flushes the files buffer
if it is an output file.
The interpreter then returns the file buffer and the files structure and window
to the free space in the heap and removes the file from the active file chain.
.NH 2
Flushing
.PP
Flushing all the file buffers at abnormal termination,
or on a call to the procedure
.I flush
or
.I message
is done by flushing
each file on the file chain that has the
FWRITE
bit set in its flags word.
.NH 2
The active file
.PP
For input-output,
.I px
maintains a notion of an active file.
Each operation that references a file makes the file
it will be using the active file and then does its operation.
A subtle point here is that one may do a procedure call to
.I write
that involves a call to a function that references another file,
thereby destroying the active file set up before the
.I write.
Thus the active file is saved at block entry
in the block mark and restored at block exit.\*(Dg
.FS
\*(dg\ It would probably be better to dispense with the notion of
active file and use another mechanism that did not involve extra
overhead on each procedure and function call.
.FE
.NH 2
File operations
.PP
Files in Pascal can be used in two distinct ways:
as the object of
.I read,
.I write,
.I get,
and
.I put
calls, or indirectly as though they were pointers.
The second use as pointers must be careful
not to destroy the active file in a reference such as
.LS
write(output, input\(ua)
.LE
or the system would incorrectly write on the input device.
.PP
The fundamental operator related to the use of a file is
.SM FNIL.
This takes the file variable, as a pointer,
insures that the pointer is not
.B nil,
and also that a usable image is in the file window,
by forcing the
.SM SYNC
bit to be cleared.
.PP
A simple example that demonstrates the use of the file operators
is given by
.LS
writeln(f)
.LE
that produces
.DS
.mD
.TS
lp-2w(8) l.
RV:\fIl f\fP
UNIT
WRITLN
.TE
.DE
.NH 2
Read operations
.SH
GET
.IP
Advance the active file to the next input element.
.SH
FNIL
.IP
A file pointer is on the stack. Insure that the associated file is active
and that the file is synced so that there is input available in the window.
.SH
READ*
.IP
If the file is a text file, read a block of text
and convert it to the internal type of the specified
operand. If the file is not a text file then
do an unformatted read of the next record.
The procedure
.SM READLN
reads upto and including the next end of line character.
.SH
READE A
.IP
The operator
.SM READE
reads a string name of an enumerated type and converts it
to its internal value.
.SM READE
takes a pointer to a data structure as shown in figure 3.2.
.so fig3.2.n
See the description of
.SM NAM
in the next section for an example.
.NH 2
Write operations
.SH
PUT
.IP
Output the element in the active file window.
.SH
WRITEF s
.IP
The argument(s) on the stack are output
by the
.I fprintf
standard
.SM I/O
library routine.
The sub-opcode
.I s
specifies the number
of longword arguments on the stack.
.SH
WRITEC
.IP
The character on the top of the stack is output
without formatting. Formatted characters must be output with
.SM WRITEF .
.SH
WRITES
.IP
The string specified by the pointer on the top of the stack is output
by the
.I fwrite
standard
.SM I/O
library routine.
All characters including nulls are printed.
.SH
WRITLN
.IP
A linefeed is output to the active file.
The line-count for the file is
incremented and checked against the line limit.
.SH
PAGE
.IP
A formfeed is output to the active file.
.SH
NAM A
.IP
The value on the top of the stack is converted to a pointer
to an enumerated type string name.
The address
.SM A
points to an enumerated type structure identical
to that used by
.SM READE .
An error is raised if the value is out of range.
The form of this structure for the predefined type
.B boolean
is shown in figure 3.3.
.so fig3.3.n
The code for
.SM NAM
is
.DS
.mD
_NAM:
\fBincl\fR lc
\fBaddl3\fR (lc)+,ap,r6 #r6 points to scalar name list
\fBmovl\fR (sp)+,r3 #r3 has data value
\fBcmpw\fR r3,(r6)+ #check value out of bounds
\fBbgequ\fR enamrng
\fBmovzwl\fR (r6)[r3],r4 #r4 has string index
\fBpushab\fR (r6)[r4] #push string pointer
\fBjmp\fR (loop)
enamrng:
\fBmovw\fR $ENAMRNG,_perrno
\fBjbr\fR error
.DE
The address of the table is calculated by adding the base address
of the interpreter code,
.I ap
to the offset pointed to by
.I lc .
The first word of the table gives the number of records and
provides a range check of the data to be output.
The pointer is then calculated as
.DS
.mD
tblbase = ap + A;
size = *tblbase++;
return(tblbase + tblbase[value]);
.DE
.SH
MAX s,w
.IP
The sub-opcode
.I s
is subtracted from the integer on the top of the stack.
The maximum of the result and the second argument,
.I w ,
replaces the value on the top of the stack.
This function verifies that variable specified
width arguments are non-negative, and meet certain minimum width
requirements.
.SH
MIN s
.IP
The minimum of the value on the top of the stack
and the sub-opcode replaces the value on the top
of the stack.
.sp 1
.LP
The uses of files and the file operations are summarized
in an example which outputs a real variable (r) with a variable
width field (i).
.LS
writeln('r =',r:i,' ',true);
.LE
that generates the code
.DS
.mD
.TS
lp-2w(8) l.
UNITOUT
FILE
CON14:1
CON14:3
LVCON:4 "r ="
WRITES
RV8\fI:l r\fP
RV4\fI:l i\fP
MAX:8 1
RV4\fI:l i\fP
MAX:1 1
LVCON:8 " %*.*E"
FILE
WRITEF:6
CONC4 \' \'
WRITEC
CON14:1
NAM \fIbool\fP
LVCON:4 "%s"
FILE
WRITEF:3
WRITLN
.TE
.DE
.PP
Here the operator
.SM UNITOUT
is an abbreviated form of the operator
.SM UNIT
that is used when the file to be made active is
.I output .
A file descriptor, record count, string size, and a pointer
to the constant string ``r ='' are pushed
and then output by
.SM WRITES .
Next the value of
.I r
is pushed on the stack
and the precision size is calculated by taking
seven less than the width, but not less than one.
This is followed by the width that is reduced by
one to leave space for the required leading blank.
If the width is too narrow, it
is expanded by
.I fprintf .
A pointer to the format string is pushed followed
by a file descriptor and the operator
.SM WRITEF
that prints out
.I r .
The value of six on
.SM WRITEF
comes from two longs for
.I r
and a long each for the precision, width, format string pointer,
and file descriptor.
The operator
.SM CONC4
pushes the
.I blank
character onto a long on the stack that is then printed out by
.SM WRITEC .
The internal representation for
.I true
is pushed as a long onto the stack and is
then replaced by a pointer to the string ``true''
by the operator
.SM NAM
using the table
.I bool
for conversion.
This string is output by the operator
.SM WRITEF
using the format string ``%s''.
Finally the operator
.SM WRITLN
appends a newline to the file.
.NH 2
File activation and status operations
.SH
UNIT*
.IP
The file pointed to by the file pointer on the top
of the stack is converted to be the active file.
The opcodes
.SM UNITINP
and
.SM UNITOUT
imply standard input and output respectively
instead of explicitly pushing their file pointers.
.SH
FILE
.IP
The standard
.SM I/O
library file descriptor associated with the active file
is pushed onto the stack.
.SH
EOF
.IP
The file pointed to by the file pointer on the top
of the stack is checked for end of file. A boolean
is returned with
.I true
indicating the end of file condition.
.SH
EOLN
.IP
The file pointed to by the file pointer on the top
of the stack is checked for end of line. A boolean
is returned with
.I true
indicating the end of line condition.
Note that only text files can check for end of line.
.NH 2
File housekeeping operations
.SH
DEFNAME
.IP
Four data items are passed on the stack;
the size of the data type associated with the file,
the maximum size of the file name,
a pointer to the file name,
and a pointer to the file variable.
A file record is created with the specified window size
and the file variable set to point to it.
The file is marked as defined but not opened.
This allows
.B program
statement association of file names with file variables
before their use by a
.SM RESET
or a
.SM REWRITE .
.SH
BUFF s
.IP
The sub-opcode is placed in the external variable
.I _bufopt
to specify the amount of I/O buffering that is desired.
The current options are:
.DS
0 \- character at a time buffering
1 \- line at a time buffering
2 \- block buffering
.DE
The default value is 1.
.SH
RESET
.br
REWRITE
.IP
Four data items are passed on the stack;
the size of the data type associated with the file,
the maximum size of the name (possibly zero),
a pointer to the file name (possibly null),
and a pointer to the file variable.
If the file has never existed it is created as in
.SM DEFNAME .
If no file name is specified and no previous name exists
(for example one created by
.SM DEFNAME
) then a system temporary name is created.
.SM RESET
then opens the file for input, while
.SM REWRITE
opens the file for output.
.sp 1
.PP
The three remaining file operations are
.SM FLUSH
that flushes the active file,
.SM REMOVE
that takes the pointer to a file name and removes the
specified file, and
.SM MESSAGE
that flushes all the output files and sets the
standard error file to be the active file.

67
share/doc/papers/px/pxin4.n
View File

@ -1,67 +0,0 @@
.\" Copyright (c) 1979 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" @(#)pxin4.n 5.2 (Berkeley) 4/17/91
.\" $FreeBSD$
.\"
.nr H1 3
.if n .ND
.NH
Conclusions
.PP
It is appropriate to consider,
given the amount of time invested in rewriting the interpreter,
whether the time was well spent, or whether a code-generator
could have been written with an equivalent amount of effort.
The Berkeley Pascal system is being modified to interface
to the code generator of the portable C compiler with
not much more work than was involved in rewritting
.I px .
However this compiler will probably not supercede the interpreter
in an instructional environment as the
necessary loading and assembly processes will slow the
compilation process to a noticeable degree.
This effect will be further exaggerated because
student users spend more time in compilation than in execution.
Measurements over the course of a quarter at Berkeley with a mixture
of students from beginning programming to upper division compiler
construction show that the amount of time in compilation exceeds the amount
of time spent in the interpreter, the ratio being approximately 60/40.
.PP
A more promising approach might have been a throw-away code generator
such as was done for the
.SM
WATFIV
.NL
system.
However the addition of high-quality post-mortem and interactive
debugging facilities become much more difficult to provide than
in the interpreter environment.

83
share/doc/papers/px/table2.1.n
View File

@ -1,83 +0,0 @@
.\" Copyright (c) 1979 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" @(#)table2.1.n 5.2 (Berkeley) 4/17/91
.\"
.DS L
.TS
box center;
c s s
c s s
c c c
n ap-2 a.
Table 2.1 \- Operator Suffixes
=
.sp
Unary operator suffixes
.sp .1i
Suffix Example Argument type
2 NEG2 Short integer (2 bytes)
4 SQR4 Long integer (4 bytes)
8 ABS8 Real (8 bytes)
.sp
_
.sp
.T&
c s s
c c c
n ap-2 a.
Binary operator suffixes
.sp .1i
Suffix Example Argument type
2 ADD2 Two short integers
24 MUL24 Short above long integer
42 REL42 Long above short integer
4 DIV4 Two long integers
28 DVD28 Short integer above real
48 REL48 Long integer above real
82 SUB82 Real above short integer
84 MUL84 Real above long integer
8 ADD8 Two reals
.sp
_
.sp
.T&
c s s
c c c
n ap-2 a.
Other Suffixes
.sp .1i
Suffix Example Argument types
T ADDT Sets
G RELG Strings
.sp
.TE
.DE

85
share/doc/papers/px/table2.2.n
View File

@ -1,85 +0,0 @@
.\" Copyright (c) 1979 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" @(#)table2.2.n 5.2 (Berkeley) 4/17/91
.\"
.DS L
.TS
box center;
c s
c | c
ci | aw(3.25i).
Table 2.2 \- Inline data type codes
_
Code Description
=
a T{
.fi
An address offset is given in the word
following the instruction.
T}
_
A T{
An address offset is given in the four bytes following the instruction.
T}
_
l T{
An index into the display
is given in the sub-opcode.
T}
_
r T{
A relational operator is encoded in the sub-opcode. (see section 2.3)
T}
_
s T{
A small integer is
placed in the sub-opcode, or in the next word
if it is zero or too large.
T}
_
v T{
Variable length inline data.
T}
_
w T{
A word value in the following word.
T}
_
W T{
A long value in the following four bytes.
T}
_
" T{
An inline constant string.
T}
.TE
.DE

45
share/doc/papers/px/table2.3.n
View File

@ -1,45 +0,0 @@
.\" Copyright (c) 1979 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" @(#)table2.3.n 5.2 (Berkeley) 4/17/91
.\"
.TS H
box center;
c s s
lw(14) | lw(12) | lw(40)
lp-2 | a | l.
Table 2.3 \- Machine operations
_
Mnemonic Reference Description
=
.TH
.so fig2.3.n
.TE

47
share/doc/papers/px/table3.1.n
View File

@ -1,47 +0,0 @@
.\" Copyright (c) 1979 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" @(#)table3.1.n 5.2 (Berkeley) 4/17/91
.\"
.TS
center;
n l l.
\-108 FNAME Text name of associated UNIX file
\-30 LCOUNT Current count of lines output
\-26 LLIMIT Maximum number of lines permitted
\-22 FBUF UNIX FILE pointer
\-18 FCHAIN Chain to next file
\-14 FLEV Pointer to associated file variable
\-10 PFNAME Pointer to name of file for error messages
\-6 FUNIT File status flags
\-4 FSIZE Size of elements in the file
0 File window element
.TE

113
share/doc/papers/px/tmac.p
View File

@ -1,113 +0,0 @@
.\" Copyright (c) 1979 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" @(#)tmac.p 5.2 (Berkeley) 4/17/91
.\" $FreeBSD$
.\"
.if n .nr FM 1.2i
.if t .tr *\(**=\(eq/\(sl+\(pl
.bd S B 3
.de mD
.ta 8n 17n 42n
..
.de SM
.if "\\$1"" .ps -2
.if !"\\$1"" \s-2\\$1\s0\\$2
..
.de LG
.if "\\$1"" .ps +2
.if !"\\$1"" \s+2\\$a\s0\\$2
..
.de HP
.nr pd \\n(PD
.nr PD 0
.if \\n(.$=0 .IP
.if \\n(.$=1 .IP "\\$1"
.if \\n(.$>=2 .IP "\\$1" "\\$2"
.nr PD \\n(pd
..
.de ZP
.nr pd \\n(PD
.nr PD 0
.PP
.nr PD \\n(pd
..
.de LS \"LS - Literal display; ASCII DS
.if \\n(.$=0 .DS
.if \\n(.$=1 \\$1
.if \\n(.$>1 \\$1 "\\$2"
.if t .tr '\'`\`^\(ua-\(mi
.if t .tr _\(ul
..
.de LE \"LE - End literal display
.DE
.tr ''``__--^^
..
.de UP
Berkeley Pascal\\$1
..
.de PD
\s-2PDP\s0
.if \\n(.$=0 11/70
.if \\n(.$>0 11/\\$1
..
.de DK
Digital Equipment Corporation\\$1
..
.de PI
.I pi \\$1
..
.de Xp
.I Pxp \\$1
..
.de XP
.I pxp \\$1
..
.de IX
.I pix \\$1
..
.de X
.I px \\$1
..
.de PX
.I px \\$1
..
.if n .ds dg +
.if t .ds dg \(dg
.if n .ds Dg \*(dg
.if t .ds Dg \v'-0.3m'\s-2\*(dg\s0\v'0.3m'
.if n .ds dd *
.if t .ds dd \(dd
.if n .ds Dd \*(dd
.if t .ds Dd \v'-0.3m'\s-2\*(dd\s0\v'0.3m'
.if n .ds b \\fI
.if t .ds b \\fB
.nr xx 1