MirOS Manual: px(PAPERS)


          Berkeley Pascal PX Implementation Notes
                Version 2.0 - January, 1979

                      William N. Joy+

                     M. Kirk McKusick*

                 Computer Science Division
 Department of Electrical Engineering and Computer Science
             University of California, Berkeley
                Berkeley, California  94720

                          ABSTRACT

          Berkeley Pascal is designed  for  interactive
     instructional  use and runs on the VAX 11/780. The
     interpreter px executes the Pascal  binaries  gen-
     erated by the Pascal translator pi.

          The PX Implementation Notes describe the gen-
     eral organization of px, detail the various opera-
     tions 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.

July 4, 2014

          Berkeley Pascal PX Implementation Notes
                Version 2.0 - January, 1979

                      William N. Joy+

                     M. Kirk McKusick*

                 Computer Science Division
 Department of Electrical Engineering and Computer Science
             University of California, Berkeley
                Berkeley, California  94720

Introduction

     These PX Implementation Notes have  been  updated  from
the   original PDP 11/70 implementation notes to reflect the
interpreter that runs on the VAX 11/780. These notes consist
of  four  major  parts.  The first part outlines the general
organization of  px.  Section  2  describes  the  operations
(instructions) of the interpreter while section 3 focuses on
input/output related activity. A final section gives conclu-
sions  about  the viability of an interpreter based approach
to language implementation for instruction.

Related Berkeley Pascal documents

     The PXP Implementation Notes give details of the inter-
nals of the execution profiler pxp; parts of the interpreter
related to pxp  are  discussed  in  section  2.10.  A  paper
describing the syntactic error recovery mechanism used in pi
was presented at the ACM Conference on Compiler Construction
in Boulder Colorado in August, 1979.

Acknowledgements

     This version of px is a PDP 11/70 to VAX 11/780  opcode
mapping of the original px that was designed and implemented
by Ken Thompson, with extensive modifications and  additions
by  William  Joy and Charles Haley. Without their work, this
Berkeley Pascal system would never have existed. These notes
were  first  written by William Joy for the PDP 11/70 imple-
mentation. We would also like to thank our  faculty  advisor
Susan  L. Graham for her encouragement, her helpful comments
and suggestions relating to Berkeley Pascal and  her  excel-
lent editorial assistance.
_________________________
+ The financial support of the National Science Founda-

                           - 2 -

1. Organization

     Most of px  is  written  in  the  VAX  11/780  assembly
language, using the UNIX- assembler as. Portions of  px  are
also  written in the UNIX systems programming language C. 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.

     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 Pas-
cal, and has 4.6K bytes of data space (constants, error mes-
sages,  etc.) a copy of which is allocated to each executing
process.

1.1. Format of the object file

     Px normally interprets the code left in an object  file
by  a  run  of  the Pascal translator pi. The file where the
translator puts the object originally, and the most commonly
interpreted  file,  is called obj. In order that all persons
using 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 pipe, creates another process by
doing a fork, and arranges that the resulting parent process
becomes an instance of px. The child process then writes the
interpreter code through the pipe that it has to the  inter-
preter  process  parent.  When this process is complete, the
child exits.

     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  treat-
ment.  A simpler mechanism would be to determine the name of
_________________________
tion  under  grants MCS74-07644-A03 and MCS78-07291 and
of an  IBM  Graduate  Fellowship  are  gratefully  ack-
nowledged.
* The financial support of  a  Howard  Hughes  Graduate
Fellowship is gratefully acknowledged.
-  UNIX  is a registered trademark of AT&T Bell Labora-
tories in the USA and other countries.

                           - 3 -

the file that was executed and pass this to the interpreter.
However  it  is  not  possible to determine this name in all
cases.*

1.2. General features of object code

     Pascal object code is  relocatable  as  all  addressing
references  for  control transfers within the code are rela-
tive. 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.

     The first byte of a Pascal interpreter instruction con-
tains  an  operation  code. This allows a total of 256 major
operation codes, and 232 of these are in use in the  current
px.  The  second  byte  of  each  interpreter instruction is
called the ``sub-operation  code'',  or  more  commonly  the
sub-opcode.  It contains a small integer that may, for exam-
ple, 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 fol-
lows  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.

     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.

1.3. Stack structure of the interpreter

     The  interpreter  emulates  a  stack-structured  Pascal
machine.  The  ``load''  instructions  put  values  onto the
stack, where  all  arithmetic  operations  take  place.  The
_________________________
* For instance, if the pxref program is placed  in  the
directory  `/usr/bin'  then when the user types ``pxref
program.p'' the first argument to the program, nominal-
ly  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.

                           - 4 -

``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.

     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 opera-
tor is used that has, implicit in its definition, the  sizes
of the arguments.

1.4. Data types in the interpreter

     The interpreter deals with several different  fundamen-
tal  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  overflow-
ing  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.

     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 intersec-
tion and an operation to write a string.

     No special packed data formats  are  supported  by  the
interpreter.  The  smallest  unit of storage occupied by any
variable is one byte. The built-ins  pack  and  unpack  thus
degenerate to simple memory to memory transfers with no spe-
cial processing.

1.5. Runtime environment

     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

                           - 5 -

input/output are allocated in the heap.

     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.+  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 goto statements.

1.6. Dp, lc, loop

     Three ``global'' variables in the interpreter, in addi-
tion  to  the ``display'', are the dp, lc, and the loop. The
dp is a pointer to the display entry for the current  block;
the  lc  is  the  abstract machine location counter; and the
loop is a register that holds the address of the main inter-
preter  loop so that returning to the loop to fetch the next
instruction is a fast operation.

1.7. The stack frame structure

     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 inter-
preter  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.  Note  that  the
local variables of each block have negative offsets from the
corresponding display entry, the  ``first''  local  variable
having offset `-2'.

1.8. The block mark

     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 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 BEG begin block operator that also allocates and  clears
the  local  variable  storage. The format of these blocks is
represented in Figure 1.2.

     The data saved by the CALL operator includes  the  line
number  lino  of  the  point of call, that is printed if the
program execution ends abnormally; the location  counter  lc
_________________________
+ Here ``block'' is being used to mean  any  procedure,
function or the main program.

                           - 6 -

     Base of stack frame

    _____________________
   |                    |
   |     Block mark     |        Positive offsets
   |                    |
   |____________________|  <- Display entry points here
   |                    |
   |        Local       |
   |      variables     |
   |                    |
   |____________________|        Negative offsets
   |      Temporary     |
   |     expression     |
   |        space       |
   |                    |
   |____________________|

     Top of stack frame

           Figure 1.1 - Structure of stack frame

       ________________________
      |                       |   Created by CALL
      |       Saved lino      |
      |                       |
      |        Saved lc       |
      |                       |
      |        Saved dp       |
      |                       |
      |_______________________|
      |                       |   Created by BEG
      |   Saved dp contents   |
      |                       |
      |   Pointer to current  |
      |     entry line and    |
      |      section name     |
      |                       |
      |   Current file name   |
      |       and buffer      |
      |                       |
      | Top of stack reference|
      |                       |
      |_______________________|

             Figure 1.2 - Block mark structure

                           - 7 -

giving the return address; and  the  current  display  entry
address dp at the time of call.

     The BEG begin operator saves the previous display  con-
tents 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 infor-
mation is stored in  the  interpreter  object  code  in-line
after the 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 LINO line number
operators in the interpreter, that occurs before each state-
ment  executed. This helps to catch bugs in the interpreter,
that often manifest themselves by  leaving  the  stack  non-
empty between statements.

     Note that there is no explicit static link  here.  Thus
to  set  up  the  display  correctly  after a non-local goto
statement one must ``unwind'' through all the block marks on
the stack to rebuild the display.

1.9. Arguments and return values

     A function returns its value into a space  reserved  by
the calling block. Arguments to a function are placed on top
of this return area. For both procedure and function  calls,
arguments are placed at the end of the expression evaluation
area of the caller. When a  function  completes,  expression
evaluation  can  continue after popping the arguments to the
function off the stack, exactly as if the function value had
been  ``loaded''.  The  arguments  to  a  procedure are also
popped off the stack by the caller after its execution ends.

                           - 8 -

     As a simple example consider the following stack struc-
ture for a call to a function f, of the form ``f(a)''.

                   ______________________
                  |      Space for      |
                  |    value returned   |
                  |        from f       |
                  |_____________________|
                  |      Value of a     |
                  |_____________________|
                  |                     |
                  |      Block Mark     |
                  |                     |
                  |_____________________|

    Figure 1.3 - Stack structure on function call `f(a)'

     If we suppose that f returns a real and that  a  is  an
integer, the calling sequence for this function would be:

        PUSH       -8
        RV4:l      a
        CALL:l     f
        POP        4

     Here we use the operator PUSH to clear  space  for  the
return  value,  load  a  on the stack with a ``right value''
operator, call the function, pop off the argument a, and can
then  complete  evaluation of the containing expression. The
operations used here will be explained in section 2.

     If the function f were given by

         10 function f(i: integer): real;
         11 begin
         12     f := i
         13 end;

then f would have code sequence:

                           - 9 -

        BEG:2      0
                   11
                   "f"
        LV:l       40
        RV4:l      32
        AS48
        END

     Here the 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 begin and the name  of  the  block  for  error
traceback.  The  BEG  operator  places a name pointer in the
block mark. The body of the function first takes an  address
of  the  function  result  variable  f  using the address of
operator LV a. The next operation in the  interpretation  of
this  function is the loading of the value of i. I is at the
level of the function f, here symbolically l, and the  first
variable  in the local variable area. The function completes
by assigning the 4 byte integer on the stack to the  8  byte
return  location,  hence  the  AS48 assignment operator, and
then uses the END operator to exit the current block.

1.10. The main interpreter loop

     The main interpreter loop is simply:

        iloop:
                caseb    (lc)+,$0,$255
                <table of opcode interpreter addresses>

     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:

        _OPER:
                cvtbl    (lc)+,r0
                bneq     L1
                cvtwl    (lc)+,r0
        L1:     ...

                           - 10 -

is all that is needed to effect this packing of  data.  This
technique saves space in the Pascal obj object code.

     The address of the instruction at iloop is always  con-
tained  in  the register variable loop. Thus a return to the
main interpreter is simply:

                jmp     (loop)

that is both quick and occupies little space.

1.11. Errors

     Errors during interpretation fall into three classes:

        1) Interpreter detected errors.
        2) Hardware detected errors.
        3) External events.

     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  deter-
mines  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 avail-
able 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.

2. Operations

2.1. Naming conventions and operation summary

     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.

                           - 11 -

      _______________________________________________
     |         Table 2.1 - Operator Suffixes        |
     |_______________________________________________|
     |                                              |
     |            Unary operator suffixes           |
     |                                              |
     | Suffix   Example         Argument type       |
     |    2      NEG2      Short integer (2 bytes)  |
     |    4      SQR4      Long integer (4 bytes)   |
     |    8      ABS8      Real (8 bytes)           |
     |                                              |
     |______________________________________________|
     |                                              |
     |           Binary operator suffixes           |
     |                                              |
     | 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                |
     |                                              |
     |______________________________________________|
     |                                              |
     |                Other Suffixes                |
     |                                              |
     | Suffix   Example         Argument types      |
     |   T       ADDT      Sets                     |
     |   G       RELG      Strings                  |
     |                                              |
     |______________________________________________|

                           - 12 -

         _________________________________________
        |   Table 2.2 - Inline data type codes   |
        |_____|__________________________________|
        | Code|            Description           |
        |______|___________________________________|
        |  a  |   An address offset is given  in |
        |     |   the  word  following  the  in- |
        |     |   struction.                     |
        |_____|__________________________________|
        |  A  |   An address offset is given  in |
        |     |   the  four  bytes following the |
        |     |   instruction.                   |
        |_____|__________________________________|
        |  l  |   An index into the  display  is |
        |     |   given in the sub-opcode.       |
        |_____|__________________________________|
        |  r  |   A relational operator  is  en- |
        |     |   coded  in the sub-opcode. (see |
        |     |   section 2.3)                   |
        |_____|__________________________________|
        |  s  |   A small integer is  placed  in |
        |     |   the sub-opcode, or in the next |
        |     |   word if  it  is  zero  or  too |
        |     |   large.                         |
        |_____|__________________________________|
        |  v  |   Variable length inline data.   |
        |_____|__________________________________|
        |  w  |   A word value in the  following |
        |     |   word.                          |
        |_____|__________________________________|
        |  W  |   A long value in the  following |
        |     |   four bytes.                    |
        |_____|__________________________________|
        |  "  |   An inline constant string.     |
        |_____|__________________________________|

                           - 13 -

____________________________________________________________________________________
|                          Table 2.3 - Machine operations                          |
|______________|______________|____________________________________________________|
|Mnemonic      |  Reference   |  Description                                       |
_|_______________|_______________|_____________________________________________________|
|ABS*          |   2.7        |  Absolute value                                    |
|ADD*          |   2.7        |  Addition                                          |
|AND           |   2.4        |  Boolean and                                       |
|ARGC          |   2.14       |  Returns number of arguments to current process    |
|ARGV          |   2.14       |  Copy specified process argument into char array   |
|AS*           |   2.5        |  Assignment operators                              |
|ASRT          |   2.12       |  Assert true to continue                           |
|ATAN          |   2.13       |  Returns arctangent of argument                    |
|BEG s,W,w,"   |   2.2,1.8    |  Write second part of block mark, enter block      |
|BUFF          |   3.11       |  Specify buffering for file "output"               |
|CALL l,A      |   2.2,1.8    |  Procedure or function call                        |
|CARD s        |   2.11       |  Cardinality of set                                |
|CASEOP*       |   2.9        |  Case statements                                   |
|CHR*          |   2.15       |  Returns integer to ascii mapping of argument      |
|CLCK          |   2.14       |  Returns user time of program                      |
|CON* v        |   2.5        |  Load constant operators                           |
|COS           |   2.13       |  Returns cos of argument                           |
|COUNT w       |   2.10       |  Count a statement count point                     |
|CTTOT s,w,w   |   2.11       |  Construct set                                     |
|DATE          |   2.14       |  Copy date into char array                         |
|DEFNAME       |   3.11       |  Attach file name for program statement files      |
|DISPOSE       |   2.15       |  Dispose of a heap allocation                      |
|DIV*          |   2.7        |  Fixed division                                    |
|DVD*          |   2.7        |  Floating division                                 |
|END           |   2.2,1.8    |  End block execution                               |
|EOF           |   3.10       |  Returns true if end of file                       |
|EOLN          |   3.10       |  Returns true if end of line on input text file    |
|EXP           |   2.13       |  Returns exponential of argument                   |
|EXPO          |   2.13       |  Returns machine representation of real exponent   |
|FILE          |   3.9        |  Push descriptor for active file                   |
|FLUSH         |   3.11       |  Flush a file                                      |
|FNIL          |   3.7        |  Check file initialized, not eof, synced           |
|FOR* a        |   2.12       |  For statements                                    |
|GET           |   3.7        |  Get next record from a file                       |
|GOTO l,A      |   2.2,1.8    |  Non-local goto statement                          |
|HALT          |   2.2        |  Produce control flow backtrace                    |
|IF a          |   2.3        |  Conditional transfer                              |
|IN s,w,w      |   2.11       |  Set membership                                    |
|INCT          |   2.11       |  Membership in a constructed set                   |
|IND*          |   2.6        |  Indirection operators                             |
|INX* s,w,w    |   2.6        |  Subscripting (indexing) operator                  |
|ITOD          |   2.12       |  Convert integer to real                           |
|ITOS          |   2.12       |  Convert integer to short integer                  |
|LINO s        |   2.2        |  Set line number, count statements                 |
|LLIMIT        |   2.14       |  Set linelimit for output text file                |
|LLV l,W       |   2.6        |  Address of operator                               |
|LN            |   2.13       |  Returns natural log of argument                   |
|LRV* l,A      |   2.5        |  Right value (load) operators                      |
|______________|______________|____________________________________________________|

                           - 14 -

____________________________________________________________________________________
|                          Table 2.3 - Machine operations                          |
|______________|______________|____________________________________________________|
|Mnemonic      |  Reference   |  Description                                       |
_|_______________|_______________|_____________________________________________________|
|LV l,w        |   2.6        |  Address of operator                               |
|MAX s,w       |   3.8        |  Maximum of top of stack and w                     |
|MESSAGE       |   3.6        |  Write to terminal                                 |
|MIN s         |   3.8        |  Minimum of top of stack and s                     |
|MOD*          |   2.7        |  Modulus                                           |
|MUL*          |   2.7        |  Multiplication                                    |
|NAM A         |   3.8        |  Convert enumerated type value to print format     |
|NEG*          |   2.7        |  Negation                                          |
|NEW s         |   2.15       |  Allocate a record on heap, set pointer to it      |
|NIL           |   2.6        |  Assert non-nil pointer                            |
|NODUMP s,W,w,"|   2.2        |  BEG main program, suppress dump                   |
|NOT           |   2.4        |  Boolean not                                       |
|ODD*          |   2.15       |  Returns true if argument is odd, false if even    |
|OFF s         |   2.5        |  Offset address, typically used for field reference|
|OR            |   2.4        |  Boolean or                                        |
|PACK s,w,w,w  |   2.15       |  Convert and copy from unpacked to packed          |
|PAGE          |   3.8        |  Output a formfeed to a text file                  |
|POP s         |   2.2,1.9    |  Pop (arguments) off stack                         |
|PRED*         |   2.7        |  Returns predecessor of argument                   |
|PUSH s        |   2.2,1.9    |  Clear space (for function result)                 |
|PUT           |   3.8        |  Output a record to a file                         |
|PXPBUF w      |   2.10       |  Initialize pxp count buffer                       |
|RANDOM        |   2.13       |  Returns random number                             |
|RANG* v       |   2.8        |  Subrange checking                                 |
|READ*         |   3.7        |  Read a record from a file                         |
|REL* r        |   2.3        |  Relational test yielding Boolean result           |
|REMOVE        |   3.11       |  Remove a file                                     |
|RESET         |   3.11       |  Open file for input                               |
|REWRITE       |   3.11       |  Open file for output                              |
|ROUND         |   2.13       |  Returns TRUNC(argument + 0.5)                     |
|RV* l,a       |   2.5        |  Right value (load) operators                      |
|SCLCK         |   2.14       |  Returns system time of program                    |
|SDUP          |   2.2        |  Duplicate top stack word                          |
|SEED          |   2.13       |  Set random seed, return old seed                  |
|SIN           |   2.13       |  Returns sin of argument                           |
|SQR*          |   2.7        |  Squaring                                          |
|SQRT          |   2.13       |  Returns square root of argument                   |
|STLIM         |   2.14       |  Set program statement limit                       |
|STOD          |   2.12       |  Convert short integer to real                     |
|STOI          |   2.12       |  Convert short to long integer                     |
|SUB*          |   2.7        |  Subtraction                                       |
|SUCC*         |   2.7        |  Returns successor of argument                     |
|TIME          |   2.14       |  Copy time into char array                         |
|TRA a         |   2.2        |  Short control transfer (local branching)          |
|TRA4 A        |   2.2        |  Long control transfer                             |
|TRACNT w,A    |   2.10       |  Count a procedure entry                           |
|TRUNC         |   2.13       |  Returns integer part of argument                  |
|UNDEF         |   2.15       |  Returns false                                     |
|______________|______________|____________________________________________________|

                           - 15 -

____________________________________________________________________________________
|                          Table 2.3 - Machine operations                          |
|______________|______________|____________________________________________________|
|Mnemonic      |  Reference   |  Description                                       |
_|_______________|_______________|_____________________________________________________|
|UNIT*         |   3.10       |  Set active file                                   |
|UNPACK s,w,w,w|   2.15       |  Convert and copy from packed to unpacked          |
|WCLCK         |   2.14       |  Returns current time stamp                        |
|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                   |
|______________|______________|____________________________________________________|

                           - 16 -

2.2. Basic control operations

HALT

     Corresponds to the Pascal procedure halt; causes execu-
     tion  to  end with a post-mortem backtrace as if a run-
     time error had occurred.

BEG s,W,w,"

     Causes the second part of the block mark to be created,
     and W bytes of local variable space to be allocated and
     cleared to zero. Stack overflow is detected here. w  is
     the  first  line  of the body of this section for error
     traceback, and the inline string (length s) the charac-
     ter representation of its name.

NODUMP s,W,w,"

     Equivalent to BEG, and used to begin the  main  program
     when  the  ``p''  option  is disabled so that the post-
     mortem backtrace will be inhibited.

END

     Complementary to the operators CALL and BEG, exits  the
     current  block,  calling  the procedure 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 flushed,
     and the interpreter is exited.

CALL l,A

     Saves the current  line  number,  return  address,  and
     active  display  entry  pointer dp in the first part of
     the block mark, then transfers to the entry point given
     by  the  relative address A, that is the beginning of a
     procedure or function at level l.

PUSH s

     Clears s bytes on the stack. Used to make space for the
     return value of a function just before calling it.

POP s

     Pop s bytes off the stack. Used  after  a  function  or
     procedure  returns  to  remove  the  arguments from the
     stack.

                           - 17 -

TRA a

     Transfer control to relative address a as a local  goto
     or part of a structured statement.

TRA4 A

     Transfer control to an absolute address as  part  of  a
     non-local goto or to branch over procedure bodies.

LINO s

     Set current line number to 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 inter-
     preter or the interpreter code has  somehow  been  dam-
     aged.  Increment  the statement count and if it exceeds
     the statement limit, generate a fault.

GOTO l,A

     Transfer control to address A that is in the  block  at
     level  l  of  the  display.  This  is a non-local goto.
     Causes each block to be exited as if with END, flushing
     and  freeing  files  with  pclose,  until  the  current
     display entry is at level l.

SDUP*

     Duplicate the word or long on the  top  of  the  stack.
     This  is used mostly for constructing sets. See section
     2.11.

2.3. If and relational operators

IF a

     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  true,  the  next
     code  is  executed,  otherwise control transfers to the
     specified address.

REL* r

     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:

                           - 18 -

             Code   Operation
             ________________
              0      a = b
              2      a <> b
              4      a < b
              6      a > b
              8      a <= b
              10     a >= b

     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.

     Consider the statement fragment:

             if a = b then

     If a and b are integers this  generates  the  following
     code:

             RV4:l      a
             RV4:l      b
             REL4       =
             IF         Else part offset

               ... Then part code ...

2.4. Boolean operators

     The Boolean  operators  AND,  OR,  and  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 false, and one a Boolean true.

2.5. Right value, constant, and assignment operators

LRV* l,A
RV* l,a

     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 LRV4:

                           - 19 -

             _LRV4:
                     cvtbl    (lc)+,r0                 #r0 has display index
                     addl3    _display(r0),(lc)+,r1    #r1 has variable address
                     pushl    (r1)                     #put value on the stack
                     jmp      (loop)

     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 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 RV14 and
     RV24 provide explicit conversion to long as the data is
     pushed. This saves the  generation  of  STOI  to  align
     arguments to C subroutines.

CON* r

     The constant operators load a value onto the stack from
     inline  code.  Small  integer  values are condensed and
     loaded by the CON1 operator, that is given by

             _CON1:
                     cvtbw    (lc)+,-(sp)
                     jmp      (loop)

     Here note that little work was required as the required
     constant  was available at (lc)+. For longer constants,
     lc must be incremented before moving the constant.  The
     operator  CON  takes a length specification in the sub-
     opcode and can be used to load strings and other  vari-
     able  length  data  onto the stack. The operators CON14
     and CON24 provide explicit conversion to  long  as  the
     constant is pushed.

AS*

     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

             i := 1

     where  i  is  a  full-length,  4  byte,  integer,  will

                           - 20 -

     generate the code sequence

             LV:l       i
             CON1:1
             AS24

     Here LV will load the address  of  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 sin-
     gle word. 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 AS24. The code sequence for AS24
     is given by:

             _AS24:
                     incl     lc
                     cvtwl    (sp)+,*(sp)+
                     jmp      (loop)

     Thus the interpreter  gets  the  single  word  off  the
     stack,  extends it to be a 4 byte integer gets the tar-
     get address off the stack, and finally stores the value
     in  the  target.  This is a typical use of the constant
     and assignment operators.

2.6. Addressing operations

LLV l,W
LV l,w

     The most common operation done by  the  interpreter  is
     the  ``left  value'' or ``address of'' operation. It is
     given by:

             _LLV:
                     cvtbl    (lc)+,r0                 #r0 has display index
                     addl3    _display(r0),(lc)+,-(sp) #push address onto the stack
                     jmp      (loop)

     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  LV
     operator has a short inline data that reduces the space
     required to address the first 32K  of  stack  space  in
     each call frame.

                           - 21 -

OFF s

     The offset operator is used in field names. Thus to get
     the address of

             p^.f1

     pi would generate the sequence

             RV:l       p
             OFF        f1

     where the RV loads the value of p, given its  block  in
     the  sub-opcode  and  offset in the following word, and
     the interpreter then adds the offset of the field f1 in
     its  record  to  get the correct address. OFF takes its
     argument in the sub-opcode if it is small enough.

NIL

     The example above is incomplete, lacking a check for  a
     nil pointer. The code generated would be

             RV:l       p
             NIL
             OFF        f1

     where the NIL operation checks for a  nil  pointer  and
     generates the appropriate runtime error if it is.

LVCON s,"

     A pointer to the specified length inline data is pushed
     onto  the stack. This is primarily used for printf type
     strings used by WRITEF. (see sections 3.6 and 3.8)

INX* s,w,w

     The operators INX2 and INX4 are used for  subscripting.
     For example, the statement

             a[i] := 2.0

     with i an integer and a an ``array [1..1000] of  real''
     would generate

                           - 22 -

             LV:l       a
             RV4:l      i
             INX4:8     1,999
             CON8       2.0
             AS8

     Here the LV operation takes the address of a and places
     it  on  the stack. The value of 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 INX2)
     where the individual elements have a size of  8  bytes.
     The code for INX4 is:

             _INX4:
                     cvtbl    (lc)+,r0
                     bneq     L1
                     cvtwl    (lc)+,r0                 #r0 has size of records
             L1:
                     cvtwl    (lc)+,r1                 #r1 has lower bound
                     movzwl   (lc)+,r2                 #r2 has upper-lower bound
                     subl3    r1,(sp)+,r3              #r3 has base subscript
                     cmpl     r3,r2                    #check for out of bounds
                     bgtru    esubscr
                     mull2    r0,r3                    #calculate byte offset
                     addl2    r3,(sp)                  #calculate actual address
                     jmp      (loop)
             esubscr:
                     movw     $ESUBSCR,_perrno
                     jbr      error

     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.

IND*

     For indirect  references  through  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 IND
     operators are necessary because of the  possibility  of
     different  length  operands. The IND14 and IND24 opera-
     tors do conversions to long as they push their data.

                           - 23 -

2.7. Arithmetic operators

     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

        Addition:       ADD*, SUCC*
        Subtraction:    SUB*, PRED*
        Multiplication: MUL*, SQR*
        Division:       DIV*, DVD*, MOD*
        Unary:          NEG*, ABS*

2.8. Range checking

     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 suf-
fices. For others, both the low and  upper  bounds  must  be
checked independently, requiring two comparisons. On the VAX
11/780 both checks are done using a single index instruction
so the only gain is in reducing the inline data.

2.9. Case operators

     The  interpreter  includes  three  operators  for  case
statements  that are used depending on the width of the case
label type. For each width, the structure of the  case  data
is the same, and is represented in figure 2.4.

     The 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.

     The 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 CASEOP1 operator has the following
code sequence:

                           - 24 -

                     _________________
                    |     CASEOP     |
                    |________________|
                    |  No. of cases  |
                    |________________|
                    |                |
                    |      Case      |
                    |    transfer    |
                    |      table     |
                    |                |
                    |________________|
                    |                |
                    |  Array of case |
                    |  label values  |
                    |                |
                    |________________|

              Figure 2.4 - Case data structure

        _CASEOP1:
                cvtbl    (lc)+,r0
                bneq     L1
                cvtwl    (lc)+,r0                 #r0 has length of case table
        L1:
                movaw    (lc)[r0],r2              #r2 has pointer to case labels
                movzwl   (sp)+,r3                 #r3 has the element to find
                locc     r3,r0,(r2)               #r0 has index of located element
                beql     caserr                   #element not found
                mnegl    r0,r0                    #calculate new lc
                cvtwl    (r2)[r0],r1              #r1 has lc offset
                addl2    r1,lc
                jmp      (loop)
        caserr:
                movw     $ECASE,_perrno
                jbr      error

     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 gen-
erates  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.

2.10. Operations supporting pxp

     The following operations are defined  to  do  execution

                           - 25 -

profiling.

PXPBUF w

     Causes the interpreter to allocate a count buffer  with
     w  four  byte  counters  and to clear them to zero. The
     count buffer is placed within an image of the  pmon.out
     file  as described in the PXP Implementation Notes. The
     contents  of  this  buffer  are  written  to  the  file
     pmon.out when the program ends.

COUNT w

     Increments the counter specified by w.

TRACNT w,A

     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.

2.11. Set operations

     The set operations: union ADDT, intersection MULT, ele-
ment   removal  SUBT,  and  the  set  relationals  RELT  are
straightforward. The following operations are more interest-
ing.

CARD s

     Takes the cardinality of a set of size s bytes  on  top
     of the stack, leaving a 2 byte integer count. CARD uses
     the ffs opcode to successively count the number of  set
     bits in the set.

CTTOT s,w,w

     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 INCT
     below. The arguments to CTTOT  include  the  number  of
     elements  s in the constructed set, the lower and upper
     bounds of the set, the two w  values,  and  a  pair  of
     values  on  the stack for each range in the set, single
     elements in constructed sets being duplicated with SDUP
     to form degenerate ranges.

IN s,w,w

     The operator in for sets. The  value  s  specifies  the
     size  of  the set, the two w values the lower and upper
     bounds of the set. The value on the stack is checked to

                           - 26 -

     be in the set on the stack, and a Boolean value of true
     or false replaces the operands.

INCT

     The operator in on a constructed set without construct-
     ing  it.  The left operand of 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

             if character in [`+', '-', `*', `/']

     or

             if character in [`a'..`z', `$', `_']

     These constructs are common in Pascal, and  INCT  makes
     them  run  much  faster  in the interpreter, as if they
     were written as an efficient series of if statements.

2.12. Miscellaneous

     Other miscellaneous operators that are present  in  the
interpreter  are  ASRT that causes the program to end if the
Boolean value on the stack is  not  true,  and  STOI,  STOD,
ITOD,  and ITOS that convert between different length arith-
metic operands for use in aligning  the  arguments  in  pro-
cedure  and function calls, and with some untyped built-ins,
such as SIN and COS.

     Finally, if the program is run with the run-time  test-
ing disabled, there are special operators for for statements
and special indexing operators for arrays that have  indivi-
dual  element  size  that  is a power of 2. The code can run
significantly faster using these operators.

2.13. Mathematical Functions

     The transcendental functions SIN, COS, ATAN,  EXP,  LN,
SQRT,  SEED,  and  RANDOM  are  taken from the standard UNIX
mathematical package. These functions take double  precision
floating point values and return the same.

     The functions EXPO, TRUNC, and ROUND take a double pre-
cision  floating  point  number.  EXPO  returns  an  integer
representing the machine representation  of  its  argument's
exponent,  TRUNC  returns  the integer part of its argument,

                           - 27 -

and ROUND returns the rounded integer part of its argument.

2.14. System functions and procedures

LLIMIT

     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.

STLIM

     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.

CLCK
SCLCK

     CLCK returns the number of milliseconds  of  user  time
     used  by  the program; SCLCK returns the number of mil-
     liseconds of system time used by the program.

WCLCK

     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.

The other system time procedures are DATE and TIME that copy
an  appropriate  text string into a pascal string array. The
function ARGC returns the number of command  line  arguments
passed  to the program. The procedure ARGV takes an index on
the stack and copies the  specified  command  line  argument
into a pascal string array.

2.15. Pascal procedures and functions

PACK s,w,w,w
UNPACK s,w,w,w

     They function as a memory to memory move  with  several
     semantic  checks.  They  do no ``unpacking'' or ``pack-
     ing'' in the true sense as the interpreter supports  no
     packed data types.

NEW s
DISPOSE s

     An LV of a pointer is passed. NEW allocates a record of
     a  specified  size  and  puts  a pointer to it into the

                           - 28 -

     pointer  variable.  DISPOSE  deallocates   the   record
     pointed to by the pointer and sets the pointer to NIL.

The function CHR* converts a suitably small integer into  an
ascii character. Its primary purpose is to do a range check.
The function ODD* returns true if its argument  is  odd  and
returns  false  if  its argument is even. The function UNDEF
always returns the value false.

3. Input/output

3.1. The files structure

     Each file in the Pascal environment is represented by a
pointer  to  a  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:

 -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

     Here 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.

     The files in the Pascal  environment,  are  all  linked
together  on  a  single file chain through the FCHAIN links.
For each file the FLEV pointer  gives  its  associated  file
variable.  These  are  used  to  free files at block exit as
described in section 3.3 below.

     The FNAME and PFNAME give the associated file name  for
the  file  and the name to be used when printing error diag-
nostics respectively. Although these names are  usually  the
same,  input and output usually have no associated file name
so the distinction is necessary.

     The FUNIT word contains a set of flags. whose represen-
tations are:

EOF      0x0100   At end-of-file

                           - 29 -

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

     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
reset and 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.

     The SYNC bit, when true, specifies  that  there  is  no
usable  image in the file buffer window. As discussed in the
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.

3.2. Initialization of files

     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  nil.  All references to an inactive file are thus refer-
ences through a nil pointer. If the Pascal  system  did  not
clear  storage to zero before execution it would not be pos-
sible 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.

     When a file is first mentioned in a  reset  or  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.

3.3. Block exit

     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

                           - 30 -

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.

3.4. Flushing

     Flushing all the file buffers at abnormal  termination,
or  on  a  call to the procedure flush or message is done by
flushing each file on the file chain that has the FWRITE bit
set in its flags word.

3.5. The active file

     For input-output, 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  opera-
tion.  A  subtle  point  here is that one may do a procedure
call to write that involves a call to a function that refer-
ences  another  file, thereby destroying the active file set
up before the write. Thus the active file is saved at  block
entry in the block mark and restored at block exit.+

3.6. File operations

     Files in Pascal can be used in two  distinct  ways:  as
the object of read, write, get, and 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 refer-
ence such as

        write(output, input^)

or the system would incorrectly write on the input device.

     The fundamental operator related to the use of  a  file
is FNIL. This takes the file variable, as a pointer, insures
that the pointer is not nil, and also that a usable image is
in the file window, by forcing the SYNC bit to be cleared.

     A simple example that demonstrates the use of the  file
operators is given by

        writeln(f)
_________________________
+ It would probably be better to dispense with the  no-
tion  of active file and use another mechanism that did
not involve extra overhead on each procedure and  func-
tion call.

                           - 31 -

that produces

        RV:l       f
        UNIT
        WRITLN

3.7. Read operations

GET

     Advance the active file to the next input element.

FNIL

     A file pointer is on the stack. Insure that the associ-
     ated file is active and that the file is synced so that
     there is input available in the window.

READ*

     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
     READLN reads upto and including the next  end  of  line
     character.

READE A

     The operator READE reads a string name of an enumerated
     type and converts it to its internal value. READE takes
     a pointer to a data structure as shown in  figure  3.2.
     See  the  description of NAM in the next section for an
     example.

3.8. Write operations

PUT

     Output the element in the active file window.

WRITEF s

     The argument(s) on the stack are output by the  fprintf
     standard  I/O  library routine. The sub-opcode s speci-
     fies the number of longword arguments on the stack.

WRITEC

     The character on the top of the stack is output without

                           - 32 -

                        _________________
                       |  No. of cases  |
                       |________________|
                       |                |
                       |     offsets    |
                       |   of element   |
                       |      names     |
                       |                |
                       |________________|
                       |                |
                       |    Array of    |
                       | null terminated|
                       |  element names |
                       |                |
                       |________________|

        Figure 3.2 - Enumerated type conversion structure

     formatting. Formatted characters must  be  output  with
     WRITEF.

WRITES

     The string specified by the pointer on the top  of  the
     stack is output by the fwrite standard I/O library rou-
     tine. All characters including nulls are printed.

WRITLN

     A linefeed is output to the active file. The line-count
     for  the  file  is  incremented and checked against the
     line limit.

PAGE

     A formfeed is output to the active file.

NAM A

     The value on the top of the stack  is  converted  to  a
     pointer  to an enumerated type string name. The address
     A points to an enumerated type structure  identical  to
     that  used by READE. An error is raised if the value is
     out of range. The form of this structure for the prede-
     fined type boolean is shown in figure 3.3. The code for
     NAM is

                           - 33 -

                           _________________
                    bool:|         2       |
                         | ________________|
                         |         6       |
                         | ________________|
                         |        12       |
                         | ________________|
                         |        17       |
                         | ________________|
                         |      "false"    |
                         | ________________|
                         |      "true"     |
                         | ________________|

         Figure 3.3 - Boolean type conversion structure

             _NAM:
                     incl     lc
                     addl3    (lc)+,ap,r6              #r6 points to scalar name list
                     movl     (sp)+,r3                 #r3 has data value
                     cmpw     r3,(r6)+                 #check value out of bounds
                     bgequ    enamrng
                     movzwl   (r6)[r3],r4              #r4 has string index
                     pushab   (r6)[r4]                 #push string pointer
                     jmp      (loop)
             enamrng:
                     movw     $ENAMRNG,_perrno
                     jbr      error

     The address of the table is calculated  by  adding  the
     base  address of the interpreter code, ap to the offset
     pointed to by 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

             tblbase = ap + A;
             size = *tblbase++;
             return(tblbase + tblbase[value]);

MAX s,w

     The sub-opcode s is subtracted from the integer on  the
     top  of  the  stack.  The maximum of the result and the
     second argument, w, replaces the value on  the  top  of
     the  stack. This function verifies that variable speci-
     fied width arguments are non-negative, and meet certain
     minimum width requirements.

                           - 34 -

MIN s

     The minimum of the value on the top of  the  stack  and
     the  sub-opcode  replaces  the  value on the top of the
     stack.

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).

        writeln('r =',r:i,' ',true);

that generates the code

        UNITOUT
        FILE
        CON14:1
        CON14:3
        LVCON:4    "r ="
        WRITES
        RV8:l      r
        RV4:l      i
        MAX:8      1
        RV4:l      i
        MAX:1      1
        LVCON:8    " %*.*E"
        FILE
        WRITEF:6
        CONC4      ' '
        WRITEC
        CON14:1
        NAM        bool
        LVCON:4    "%s"
        FILE
        WRITEF:3
        WRITLN

     Here the operator UNITOUT is an abbreviated form of the
operator  UNIT  that is used when the file to be made active
is output. A file descriptor, record count, string size, and
a pointer to the constant string ``r ='' are pushed and then
output by WRITES. Next the value of 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  fprintf.  A  pointer  to  the format string is
pushed followed by a file descriptor and the operator WRITEF
that prints out r. The value of six on WRITEF comes from two

                           - 35 -

longs for r and a long each for the precision, width, format
string  pointer,  and  file  descriptor.  The operator CONC4
pushes the blank character onto a long on the stack that  is
then  printed out by WRITEC. The internal representation for
true is pushed as a long onto the stack and is then replaced
by  a  pointer  to  the  string ``true'' by the operator NAM
using the table bool for conversion. This string  is  output
by  the  operator  WRITEF  using  the  format string ``%s''.
Finally the operator WRITLN appends a newline to the file.

3.9. File activation and status operations

UNIT*

     The file pointed to by the file pointer on the  top  of
     the  stack  is  converted  to  be  the active file. The
     opcodes UNITINP and UNITOUT imply  standard  input  and
     output respectively instead of explicitly pushing their
     file pointers.

FILE

     The standard I/O  library  file  descriptor  associated
     with the active file is pushed onto the stack.

EOF

     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 true indicating the end  of  file  condi-
     tion.

EOLN

     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 true indicating the end  of  line  condi-
     tion.  Note  that  only text files can check for end of
     line.

3.10. File housekeeping operations

DEFNAME

     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  program  statement
     association  of  file  names with file variables before
     their use by a RESET or a REWRITE.

                           - 36 -

BUFF s

     The sub-opcode  is  placed  in  the  external  variable
     _bufopt  to specify the amount of I/O buffering that is
     desired. The current options are:

             0 - character at a time buffering
             1 - line at a time buffering
             2 - block buffering

     The default value is 1.

RESET
REWRITE

     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 vari-
     able. If the file has never existed it is created as in
     DEFNAME.  If  no file name is specified and no previous
     name exists (for example one created by DEFNAME )  then
     a  system  temporary  name is created. RESET then opens
     the file for input, while REWRITE opens  the  file  for
     output.

     The three remaining  file  operations  are  FLUSH  that
flushes  the active file, REMOVE that takes the pointer to a
file name and removes the specified file, and  MESSAGE  that
flushes  all  the  output  files and sets the standard error
file to be the active file.

4. Conclusions

     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 px.  However  this  compiler
will  probably  not supercede the interpreter in an instruc-
tional environment as the  necessary  loading  and  assembly
processes  will slow the compilation process to a noticeable
degree. This effect will be further exaggerated because stu-
dent 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.

                           - 37 -

     A more promising approach might have been a  throw-away
code  generator such as was done for the WATFIV system. How-
ever the addition of high-quality post-mortem  and  interac-
tive debugging facilities become much more difficult to pro-
vide than in the interpreter environment.

Generated on 2014-07-04 21:17:45 by $MirOS: src/scripts/roff2htm,v 1.79 2014/02/10 00:36:11 tg Exp $

These manual pages and other documentation are copyrighted by their respective writers; their source is available at our CVSweb, AnonCVS, and other mirrors. The rest is Copyright © 2002‒2014 The MirOS Project, Germany.
This product includes material provided by Thorsten Glaser.

This manual page’s HTML representation is supposed to be valid XHTML/1.1; if not, please send a bug report – diffs preferred.