There are 4 other files named pascal.opr in the archive. Click here to see a list.
If you are a Tops-20 system, you should ask for the Tops-20 native
mode version of this system. Contact
Charles L. Hedrick
P.O. Box 879
Piscataway, NJ 08854
and enclose a blank tape (or $10) and return postage. This version
will run on Tops-20 under the emulator, but is not as well designed
as the Tops-20 version, and certainly does not support the 20 as well.
NOTE: We are now using Tops-20 here at Rutgers. The Tops-10 Pascal
compiler has been modified to run under the emulator. We have
checked edit 74 to be sure that it works on a real Tops-10 site, but
it is still possible that the version you have won't work. If it
doesn't, please notify Charles Hedrick at the address given above.
Enclosed are the files for the CSL edition of PASCAL. This edition
is not meant to replace the one distributed by Prof. Nagel, but
rather to be a supplement until we can get together with Prof. Nagel
on a common version. We believe that the enhancements present in
this version make it a dramatically better language for certain
system programming tasks, although for many users the only real
improvement will be the ability to specify file names using the usual
DEC-10 file spec in RESET and REWRITE, and possibly the ability to
read strings using the READ and READLN statements. Note that this
version has not undergone the sort of testing that we would like. We
consider this a "field test" edition at best. You may be assured
that we have exercized all of the code in our patches, so there are
no gross errors. But we do not doubt that some more subtle ones are
there. (In particular we have had to resort to simulating certain of
the error recovery procedures, since it was not easy to find
files with errors in them on this system.)
The parts most likely to give problems are the new runtime features.
It is unlikely that any facility will fail as a whole, since each has
been used in some program here. (We have an edit-in-place video
editor that is full of dump-mode I/O, updating, renaming, etc.) The
most likely problems are with error handling and magtape processing.
These have not been used in any real program yet. LOOKUP and ENTER
failures are probably handled correctly. The kind of error handling
I am referring to is the ability to specify that you want certain
errors to be ignored, e.g. tape parity errors. I would not be
surprised to find that recovery from some of these errors doesn't
work. When looking at that code, do not assume that I understand
correctly what the monitor does. Indeed misunderstanding of the
monitor is more likely than simple coding errors. We have had
essentially no problem with the actual code generation. We salute
Prof. Nagel, as the Hamburg compiler is by far the most solid product
of this size we have ever seen come out of a university.
One warning to begin with: Our implementation of dynamic memory
expansion will work only on virtual memory machines. This is because
the stack and heap are allocated using the PAGE. UUO. I have no
doubt that a sufficiently clever programmer could find a way to do it
all in one contiguous segment of core, but the time it would take to
do this was not worth it to us. Sorry about that. We believe that
the benfits of having automatic core expansion outweigh the problems
of KA-10 incompatibility. There is a KA-10 version, but it uses the
same fixed core allocation as the Hamburg version. If you are a KA,
and told us that you are, you presumably have the KA-10 version. If
so, you should read KA.OPR, which will describe the KA-specific files
and implementation issues.
The general philosophy of this implementation is to give the user
access to all of the facilities of the TOPS-10 monitor, while not
violating the basic design principles of PASCAL. Thus we have added
lots of special I/O procedures, but have not added strings, or
anything else that would require a runtime memory management system.
(In particular, we have rejected implementing the DISPOSE function.)
The source files needed for the compiler are
PASCMP.PAS - the compiler itself
PASSCN.MAC - a small program that calls SCAN to get the command
PASLNK.MAC - a short function which is called by PASCMP to return
the data generated by SCAN, in a format appropriate for
To load the compiler, use the command file PASCAL.CCL. I.e.
If the current version of the runtimes are not on the system, you
ASSIGN DSK SYS
I generate Pascal under Tops-20. One cannot run a Tops-20 .EXE file on
Tops-10 without some care. I have written a program REVERT which does
the appropriate magic to the directory of the .EXE file. It is really
not quite general purpose, but should work with most "normal" two
segment programs, assuming DEC doesn't change something in either
Tops-10 or Tops-20. I usually run REVERT on all .EXE files before
shipping a tape to a Tops-10 site. But if you ever try to run PASCAL.EXE
and get really strange results (e.g. "not an .EXE file"), try
EXE_FILE : PASCAL.EXE
Pascal is designed so you can make a two-segment version. In this
configuration the command scanner and the compiler are in separate
high segments, which GETSEG each other, much as LINK's various phases
do. The files involved with this are TWOSEG.RUN, TWOSEG.CTL, PASA.CCL,
PASB.CCL, PAS1.CCL, and PAS2.CCL. Unfortunately, LINK no longer
supports the switch needed to do this, so I am no longer supporting
this configuration. It only saved 4K, which didn't seem worth much
worry. You can probably save more than that just by reloading under
Tops-10. This is because LINK leaves local symbols in the core image
under Tops-20, but not under Tops-10.
We have never assembled all of the runtimes at once. Rather, we use
MAKLIB to replace individual modules. One or two of the modules have
never been touched, and are thus exactly the same as those Prof.
Nagel supplied. The main runtime, and the one you are most likely to
change, is PASIO.MAC. XIO.MAC and TTCALL.MAC contain useful
procedures that are not part of the language itself, but may be
declared EXTERN in your source file. They are documented in the .DOC
file. PARSE.PAS is the source for the file name parser. It is used
by RUNTIM. No doubt space and efficiency could be gained if it were
coded in MACRO, but we did not think the gains worth it. GETFIL.MAC
is the source for the routine that gets file names as specified by
the PROGRAM statement. RANDIO.MAC is the source for the routines used
for random access and blocked I/O. There are no doubt some
other runtimes I have forgotten here, but all should be listed in
If you don't need to change the compiler, simply put the file
PASCAL.EXE on SYS:.
The following are the source files for the runtimes:
PASIO.MAC - major I/O routines
PASNUM.MAC - number and string input and output
DEBUG.PAS - pasddt itself, the portion that is in PASLIB
PARSE.PAS - file name scanner
TTCALL.MAC - implements TTCALL's
XIO.MAC - minor I/O things
GETFIL.MAC - implements the PROGRAM statement
RANDIO.MAC - random access I/O functions
PASSET.MAC - used for handling SET OF CHAR
HEAP.MAC - the memory management loaded to implement
NEW and DISPOSE when DISPOSE is used.
PASCMD.MAC - COMND jsys simulation package (not finished - see
PASCMD.PAS for its current state)
CMPARS.PAS - file name scanner for PASCMD
The resulting .REL files are combined by MAKLIB (or FUDGE2) to form
PASLIB.REL, the library. You should probably use /INDEX, too.
We have never generated PASLIB from scratch, but use MAKLIB to replace
only the module we have changed. The compiler automatically inserts
a request to load SYS:PASLIB.REL in every PASCAL main program. So if
you don't put PASLIB on SYS:, you will have to modify the compiler.
The file PASPRM.PAS contains the device and PPN (as separate project
and programmer numbers) on which PASLIB will be found. When you
change PASPRM, you have to recompile the compiler.
PASDDT is a special case. It consists of 2 parts:
DEBUG.PAS - the largest part of the code - part of PASLIB
PASDDT.MAC - assembly language support routines
The user (or COMPIL in his behalf) loads PASDDT when he wants to
debug. Since PASDDT contains a reference to a symbol in DEBUG, DEBUG
is automatically included from the library. PASDDT.MAC is a very
short file containing linkages to DEBUG. It is intended to be put on
SYS: as PASDDT.REL. COMPIL has it loaded as the first file when a
DEBUG command is given for a PASCAL program. Note that we depend
upon the fact that PASDDT sets only the right half of .JBDDT, leaving
the left half zero. (Both the main programs and the runtimes assume
that if RH(.JBDDT) <> 0 and LH(.JBDDT)=0, then we have PASDDT. Thus
they distinguish PASDDT from DDT by the fact that DDT sets LH(.JBDDT)
PASDEB.MAC is the source for SYS:PASDEB.REL. It is a routine with
proper linkages for having both DDT and PASDDT in at the same time.
If you do not want to assemble the runtimes, just put the following
files on SYS:
PASLIB.REL - library
PASDDT.REL - debugger linkage
PASDEB.REL - for using PASDDT and DDT at the same time
PASCAL.RND - source for the full manual
PASCAL.DOC - the full manual
PASCAL.MSS - source for the newer, more readable manual
which however leaves out some of the more
PASCAL.MEM - the newer manual
PASCAL.MSS is intended to be compiled by SCRIBE. This is a
powerful document preparation system written by Brian Reid
at Carnegie-Mellon University. This system is now available
605 Devonshire St.
Pittsburgh, Pa. 15213
COMPIL.SCM shows the patches we have made to COMPIL, both for
switch-passing and to make the DEBUG command work. We do
not recommend using our PASCAL without these modifications.
********package for use with PASCAL**********
We are supplying two packages for use with PASCAL: SCAN/WILD and
PSI. SCN.MAC is a prototype. It will require slight customization
for each application. It is very carefully documented internally,
and should be fairly easy to use, if you understand generally what
SCAN and WILD do. This approach is better than writing super-general
routines, I believe. (I speak from some experience, having taken the
latter approach with a SCAN/WILD interface for SAIL.) The PSI
routines are well explained in PASPSI.DOC. Note that to use SCAN
with PASCAL, you must edit SCAN.MAC (Actually SCN7B.MAC) and
HELPER.MAC. Both of these files are supplied by DEC. (Don't confuse
SCAN.MAC, which is the DEC module with SCN.MAC, which is our
interface to it.) Both of these gems use CORE UUO's to return core
(rather stupidly in the case of SCAN). The CORE UUO's should be
removed, as they kill the page allocations done by the PASCAL
runtime. I supply SCN7BX and HELPX, which have been correctly
edited. (I just replace the CORE's with SKIPA's using FILDDT.)
In the long run, I think SCAN will be replaced by the package
that simulates the Tops-20 COMND jsys. It is far more convenient
to use in a high-level language. See PASCMD.PAS for documentation
on this. Unfortunately not all functions available on Tops-20 are
We are also including the Peter DeWolf's IPCF package. This system
is language-independent in principle and uses a single
source for PASCAL, SAIL, FORTRAN, and BLISS. However an
assembly switch LANGUAGE must be set to control the language, since
each has somewhat different routine calling mechanisms. The
source is set up for the PASCAL version as included here. For
F10, you should set CORMAN to 0. For other languages, see the
comments in the source file. The PASCAL version seems to be set up
to be declared as FORTRAN procedures, but see the manual.
There is also a routine for handling PTY's. It is PASPTY.MAC. See
the file, as it has built-in documentation.
FORTIO.MAC is a set of routines to allow calling Fortran subroutines
that do Fortran I/O. It has not been tested much. But at least it
will be a help to anyone who has to do this sort of interface.
It attacks only the memory management problem. Nothing is done to
prevent Pascal and Fortran from trying to use the same I/O channels.
The best way to handle that would be to separate FNDCHN and a routine
for releasing channels from PASIO into a different module. Then a
version of these routines could be supplied that used the Fortran
channel management (ALCHN. and DECHN.).
PFORM.PAS is a formatter. It is offered as an alternative to
CROSS. The other purpose of cross was to produce a crossreference
listing. I believe the the /CREF switch, together with DEC's
CREF program, do a better job of this. This formatter is
from Stanford. I have not tested it significantly, and make
no guarantees about it. When compiling it, you must have
P: defined as a logical device pointing to some directory on
which the file PASCMD.PAS is resident. You must load this program
with PFORMS.MAC, which contains some system-specific subroutines.
We would be happy to hear what your experience is with this system.
No doubt we will end up fixing bugs that may be reported, although
I will make no committments to that effect. You should not expect
quite the quality of maintenance that we give for Tops-20 Pascal,
however, as all testing has to be done using the emulator, and
even the format of .EXE files is a bit different!
To put our version on the system, you need to transfer the
following files to SYS:
PASCAL.EXE, PASLIB.REL, PASDDT.REL, PASDEB.REL
You should also modify COMPIL to add PASCAL as a known processor,
with extension .PAS. Note that PASCAL uses SCAN as its top level.
Thus the patches in COMPIL for F10 should be used for PASCAL. (One
hopes that DEC will eventually extend COMPIL so there is a parameter
in the X macro to specify that the language uses SCAN. This has been
added by at least one site.) Our modifications are included as
COMPIL.SCM. We have a number of modifications not relevant to
PASCAL. They have edited out of the .SCM file. I mention this
because it means that the .SCM file has been touched by human
hands, and may possibly have been messed up (though I doubt