Version II.0, February 1979
The UCSD Pascal system described in this document is a system
intended to run on stand alone micro- and mini-computers. This system
is highly machine independent since it runs on a pseudo-machine
interpreter commonly referred to as the “P-machine”. All system
software is written in Pascal, except for the P-machine interpreter
and a few run-time support routines written in assembler for
efficiency, resulting in relatively straightforward software
maintenance and enhancement.
The system is designed to be used primarily with a CRT terminal acting as the CONSOLE device; however, the system is flexible enough to be reconfigured for slower hard-copy terminals. The system does require some kind of fast mass storage such as a floppy disk system or better. For further information regarding compatibility between various types of equipment and this system see the “SETUP” document in Section 4.3. This document is intended for programmers who are familiar with the Pascal programming language and have some experience in writing computer programs. Some additional reading suggestions follow:
The following is a tutorial book on PASCAL:
Kenneth L. Bowles,
(Microcomputer) Problem Solving Using PASCAL
Springer-Verlag, New York, © 1977
We suggest the following book as a PASCAL reference guide:
Kathleen Jensen and Niklaus Wirth,
PASCAL User Manual and Report
Springer-Verlag, New York, © 1975
For documentation concerning the differences between UCSD Pascal and Standard Pascal see Section 2.2.
The structure of the UCSD Pascal system is best conceptualized in terms of the “tree-like” structure diagram figure 0.1.
The diagram in figure 0.1 depicts the outermost level of the
system. In terms of a “tree” or structure diagram, the
“root”
corresponds to the outermost level, while the “leaves”
(i.e. the boxes
with no branches to lower levels) correspond to the lower levels of
the system. While a user is in a particular level, the system
displays a list of available commands called the “prompt-line”. If
the system is running on a CRT screen type terminal, then the
prompt-line
will usually appear at the top of the screen. Commands are
usually invoked by typing a single character from the CONSOLE device.
For example, the prompt-line for the outermost level of the system is:
Command: E(dit, R(un, F(ile, C(omp, L(ink, X(ecute, A(ssem, D(ebug, ? [II.0]
By typing “F” the user will “descend” a level within the structure diagram into a level called the “Filer”. Upon entering the Filer, another prompt-line detailing the set of commands available at the Filer level of the system is displayed. The Q(uit command causes the user to exit from the Filer and “ascend” back to the outermost command level of the system. Now the user is back at the level in the system from which he started after bootstrapping the machine. Some commands within the system prompt the user for the name of some file. In these cases, the user enters the name of the file followed by a carriage return. If an error is made in typing a portion of the file name, the backspace key (or equivalent key depending upon the system configuration) may be used to “back over” and erase the erroneous part. The line delete key (rubout key) may be used to erase the entire file name, thereby allowing the user to completely start over. If the user decides not to accept any file name whatsoever, “escape” from this command is by entering a file name of zero characters, i.e. type <cr>.
Sometimes there are more commands than will fit on the screen. If this is true, a question mark (?) will appear at the end of the line, typing “?” will cause a different prompt to appear, such that more of the available commands will be displayed to the user.
A concept central to the design of the entire UCSD Pascal system command structure is the concept of the “workfile”. A workfile can be thought of as a “scratch-pad” area used for development of programs and only one workfile is allowed at any one time. If a user wishes to begin a new workfile, the contents of the old one can be saved, under a separate file name, for later reference by using the S(ave command in the Filer level of the system. When that file is later retrieved for further work on the contents, it is possible that a number of files (usually source and code) will be retrieved together and in total they comprise the work-file.
Typing “E” while at the outermost command level of the system
causes the editor program to be brought into memory from disk. The
user may, while in the editor, alter text inside his workfile or any
textfile. See Section
1.3
for details. The workfile text (if present)
is read into the editor buffer, otherwise the Editor prompts for a
file.
“F” places the user in a level of the system called the Filer. This section of the system contains commands used primarily for maintenance of the disk directory. For more documentation on the Filer level including commands associated with the “getting”, “saving”, and “clearing” of the user's workfile see Section 1.2.
This command initiates the system compiler to compile the users workfile. If there is no work-file currently the user is asked for a source text file name. If a syntax error within the source is detected, the compiler will stop and display the error number and the surrounding text of the program. By typing a space, the user can cause the compiler to continue the compilation. Typing an <esc> causes the compiler to abort and return to Command level. Typing ‘E’ will call the editor placing the cursor, if the system editor is the screen editor, near the offending symbol. If the compilation is successful, (i.e. no compilation errors were encountered) a code file called SYSTEM.WRK.CODE is written out onto the user's disk and becomes part of the workfile. For more documentation on the use of the UCSD Pascal compiler see Section 1.6.
This command causes the code file associated with the current workfile to be executed. If no such code file currently exists, the compiler is called in the same manner as described in C(omp above. If the compilation requires linkage to separately compiled code the linker will automatically be invoked and will assume the use of the file *SYSTEM.LIBRARY. After a successful compilation, the program is executed.
This command prompts the user for the filename of a previously compiled codefile. If the file exists, the code file is executed; otherwise the message “can't find file” is returned. (Note: the “.CODE” suffix on such a file is implicit.) If all code necessary to execute the codefile has not been linked in, the message “must L(ink first” is returned. It is convenient to X(ecute other programs which have already been compiled because otherwise the user would have to enter the Filer, G(et the file, Q(uit the Filer, and then R(un the program.
A(ssemJust like C(omp except the system assembler is invoked rather than the system compiler. See Section 1.9 for more information on the system assembler.
This command causes the current workfile to be executed. If the program in the workfile has not been compiled, the compiler will be called as in the case of the R(un command. However if a run-time error occurs, or a user-defined breakpoint or halt is encountered, the Debugger program is called. The Debugger is a program which allows the user to examine the contents of variables within the program. See section 1.5 Debugger for more details.
This command starts the system linker program explicitly to allow users to link routines from libraries other than “SYSTEM.LIBRARY”. See section 1.8 for more information on the Linker.
There are many functions needed by users of any operating system. To attempt to make all these functions system functions would result in a terrible proliferation of command letters at the base node level. In order to keep the COMMAND line simple, we have restricted the functions available on it to what we feel is the bare minimum for program and text development. The other useful, but much less often used, functions are available through the X(ecute command. The sort of functions which are available are the desk calculator, the patch/jump utility, the terminal configuration setup program, a bootstrap mover, a librarian and many others. For a complete list of the utility programs now available with the UCSD Pascal system, reference Section 4 in the Table of Contents. Any programs which you write and feel would be a useful addition to our library of utilities will be welcome contributions.
I.5 is the first release which contains the fully integrated and implemented concept of separate compilation and assembly. I.4b was the first to support multiple types of processors. I.3 was the first releasable system.
The great bulk of the system software is written in Pascal and
runs on a relatively simple pseudo-machine. If this pseudo-machine is
emulated by a machine language program on a new real machine, the
Pascal software will also run on that new real machine.
One class of differences among versions of the system is due to aspects of the pseudo-machine that are not identically emulated by the implementations for different types of processors. Section A contains a chart of differences between processors the system currently runs on.
Another class of differences stems from variations in the system I/O environments rather than in the host processor. Included here are differences in system console terminal types (i.e. hard-copy vs CRT vs storage tube) or command conventions and capabilities (e.g. “intelligent” vs “dumb” CRTs). The system is intended to be able to cope with this sort of variation.
In the PDP-11 world these mass storage variations are not too serious, primarily because there is considerable motivation to be compatible with DEC devices and media. We have written and support drivers for a few DEC incompatible devices but make no claim to support users who want to develop their own such drivers. See section A for warnings about problems you might encounter.
The situation in the 8080/Z80 world is much more chaotic. Since it would not be practical for the Project to write and support drivers for the vast multitude of 8080/Z80 I/O environments that exist, we have chosen to take advantage of the widespread implementation of Digital Research's CP/M operating system by structuring the pseudo-machine's I/O operations as calls on CP/M's Basic I/O Subsystem (BIOS) primitives. Therefore, any I/O configuration on which CP/M has been implemented should also be able to support the Pascal system. We do not guarantee this. For example, Intel MES disk controllers cannot read disks generated here and some BIOSs we have encountered do not completely meet all the requirements specified for CP/M. UCSD plans to support some of the larger distribution 8080-based machines directly.
Our dominant mode of distribution is on 3740 compatible diskettes. One of the distribution diskettes for Z80/8080 systems will be CP/M oriented. This disk will be used, via a somewhat awkward two-step process, to bring up UCSD Pascal on a particular CP/M configuration. Look to section A for details on this process. It also describes the configuration of a modified BIOS, which will better support the needs of the Pascal system. Finally, directions are given for making it possible to boot directly to Pascal rather than indirectly through a CP/M program.
A number of files on the disk start with “SYSTEM.” specifically:
SYSTEM.PDP-11
SYSTEM.MICRO
SYSTEM.PASCAL
SYSTEM.SYNTAX
SYSTEM.ASSMBLER
SYSTEM.COMPILER
SYSTEM.EDITOR
SYSTEM.FILER
SYSTEM.LINKER
SYSTEM.STARTUP
SYSTEM.SWAPDISK
SYSTEM.CHARSET
SYSTEM.LIBRARY
SYSTEM.WORK.TEXT
SYSTEM.WRK.CODE
SYSTEM.WRK.INFO
SYSTEM.LST.TEXT
In most cases these files contain the system segment of the name they carry. That is to say that the EDITOR, FILER, LINKER, COMPILER, ASSEMBLER are the files that are invoked by the main level. of the system when ‘E’, ‘F’, etc is typed. Some of the files are machine specific. PDP-11 and MICRO are the files which contain the interpreters for the particular machine being used. CHARSET is a file which appears on disks meant for TERAK computers only and contains the definition for the soft character set, and the data for the Triton logo prompt. LIBRARY is a file containing separately assembled or compiled routines for use by the Linker in producing executable code files. PASCAL contains the operating system, and the Debugger. SWAPDISK is a file used by some of the system segments during open/close operations on files if a memory shortage exists. It is a 2048 byte file which gets a portion of memory swapped to it when a directory needs to be read into core. When the directory work is complete, the memory is restored to its original state. STARTUP is a file which can be created at the user's option. If it exists on a disk, the operating system considers it a runnable code-file, and executes it at initialize time. This allows the user to have a program that runs before the main command prompt comes up, and will run anytime the I(nitialize command is typed. WRK.TEXT and WRK.CODE are the current work-file after some action has occurred to the work-file. They appear after having done some text editing on a work-file (SYSTEM.WRK.TEXT) or compiling a work-file (SYSTEM.WRK.CODE). To change the editor which is invoked by “E”, one simply names the codefile which is to respond to the ‘E(dit’ command SYSTEM.EDITOR. This is true for all system segments which have named files associated with their command.
All other files on the disk are user generated (in one fashion or another). The other important parts of a disk are relatively invisible to the user. The directory resides at block 2 on the disk and extends for 4 blocks if it is a single directory, 8 blocks if it is a duplicated (backed-up) directory. The bootstrap can reside at any of a number of places on the disk, depending on the host machine. In most cases, blocks 0 and 1 are reserved for the bootstrap.