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. October 6, 2015 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 2015-10-06 19:36:22 by $MirOS: src/scripts/roff2htm,v 1.80 2015/01/02 13:54:19 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–2015 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.