Enter your search terms Submit search form
	Web pdp-10.trailing-edge.com

If you are a Tops-20 system, you should ask for the Tops-20 native 
mode version of this system.  Contact
  Charles L. Hedrick
  CCIS
  Rutgers University
  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.)

**************compiler*************

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
	string.
PASLNK.MAC - a short function which is called by PASCMP to return
	the data generated by SCAN, in a format appropriate for
	PASCAL.

To load the compiler, use the command file PASCAL.CCL. I.e.
  R LINK
  *@PASCAL
  */G
  SAVE PASCAL
If the current version of the runtimes are not on the system, you
should do
  R SETSRC
  *SYS
  *^C
  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 
  RU REVERT
  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.  If anyone wants to play with
this configuration and is running under 7.01, these control files
will not work, since the OSAVE command is no longer present.  I am
including a file TWO701.OPR that explains how to build a twoseg version
under 7.01

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
FILES.DIR.

If you don't need to change the compiler, simply put the file
PASCAL.EXE on SYS:.

**************runtimes*****************

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

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

***********documentation**********

	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
			abstruse features
	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
from

  Unilogic, Ltd.
  605 Devonshire St.
  Pittsburgh, Pa. 15213


***********COMPIL linkage***********

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
implemented yet.

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.


***************concluding comments***********


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