Google
 

Trailing-Edge - PDP-10 Archives - decuslib10-11 - 43,50531/ka.opr
There are no other files named ka.opr in the archive.
The file is a supplement to PASCAL.OPR for the KA-10 distribution.  The
KA is special for the following reasons:
  - the KA version of the system is special because the KA does not
	support the virtual memory facilities needed for our dynamic
	memory management
  - the KA distribution is special because we do not keep a complete
	set of KA files on line
  - there is also the problem that many KA sites seem to be running badly
	out of date software, and would not be able to use the KA version
	in the form we generate it locally.

The first problem is discussed completely in PASCAL.DOC, particular in
section 1.2.  The REENTER command mentioned there is peculiar to the
KA-10 version.  The implementation of REENTER in the compiler is done
by the files CMPCOR.MAC, which is therefore peculiar to the KA-10
implementation.  (The REE code for normal programs is in the runtimes.
CMPCOR is needed for the compiler because of the two segment construction.
It has to be put in the low segment, and the REE code in the runtimes
is in the high segment.)

While we do have a separate directory for KA-10 files, we do not keep a
complete set of files on it.  We use it by resetting our search list
to first look at that directory and then the one on which the main
Tops-10 distribution is kept.  So we recommend that you first load the
main Tops-10 distribution, and then read the KA-10 save set into the
same directory.  This will give you one directory with all the files,
and will cause any KA-10 files to overwrite the Tops-10 files of the
same name.  Most of the files are different only because they have
a different assembly switch setting.  The two places that have to be
changed are PASPRM.PAS, where you have to turn KA10 on, and PASUNV.MAC,
where you have to turn KA10SW on (and reassemble, to produce a new
.UNV file).  The rest of the source files take their switch settings
from these two.  At the moment the KA10 area contains .REL files for
all of the files that depend upon those switch settings.

We had a rather unsettling experience trying to test the KA version.
The first KA I tried to use turns out to be running version 5.06
of the monitor and all of its system software is out of date.  Thus it
could not load our .EXE files, and their copy of LINK could not load
SCN7B (because it uses Polish fixups, and their LINK and LOADER both
fail on it, in different ways).  Since it is fairly common for KA's to
be out of date in this way, we have tried to make this distribution as
self-sufficient as possible.  We have included a version of LOADER,
in case you do not have a loader or LINK that will work.  The way
to use LINK is documented in PASCAL.OPR.  If you have to use LOADER,
it works similarly, but you use the following LOADER commands:
   R LOADER
   *PASCAL.CCL@
   SAVE PASCAL
You would still run SETSRC and do ASS DSK SYS.  If LOADER is unable
to find all the files, you may have to add
   PASLIB/L,SYS:FORLIB/L
For some reason, doing this confuses LINK, so it is not normally in
the file.

We have supplied PASCAL.EXE, which is the result of this process.  The
following things could go wrong:
  - you can't load our PASCAL.EXE and PASCMP.EXE because your monitor
	does not support .EXE files.  If that is the case, you should
	try using FILEX, which we supply as part of the normal Tops-10
	distribution.  
		.R FILEX
		*file.SHR=file.EXE
		*^C
  - you don't have LINK, or your LINK blows up trying to load SCN7B.
	In that case you should either get a good LINK, or load with
	the enclosed copy of LOADER.

We occasionally test this version on a real KA-10.  When we do that, we
use FILEX to make PASCAL.LOW and PASCAL.SHR.  Thus PASCAL.LOW and
PASCAL.SHR are the most recent versions actually tested on a KA-10. You
should use PASCAL.EXE if you can, and produce your own .LOW and .SHR
files if you need them. The tests are done on KA-10's at CMU and
Harvard.  CMU is running 5.06B, and Harvard is running 5.07.  It works
at both sites. However at CMU TRMOP. is not available, so that openning
TTY's as files uses normal IN and OUT uuo's.  This affects the user
because it means he will have to use BREAK to force out output.  On
monitors with TRMOP. characters are put out one by one.  Of course the
Pascal file TTY always uses TTCALL's, so it is never necessary to BREAK
on TTY.

If you are concerned about the size of the compiler, you can take the
following steps:
 - reload the compiler.  Tops-20 LINK always leaves the symbols in.  If
	you load it with Tops-10 LINK it will not have a symbol table.
	That can save as much as 2K.  It will make debugging more
	difficult, but might be worth it.
 - reduce the amount of space allocated to the stack and heap in the
	compiler.  You can do this by changing the {$H:nnn} in
	PASPRM.PAS and recompiling, etc.  Or you can take the
	version we give you, GET it, do REE and let Pascal reset
	its own space allocation.  When it EXIT's, you would SAVE or
	SSAVE it.  I have currently set PASCAL up with enough space
	to compile itself.  In a student environment, that may be
	more than is needed.  2K seems an absolute minimum, but
	I think you might want something more like 4K.

Because of the fact that KA sites are often short on core, we have
left CIXMAX (in PASPRM) at 1500.  The other versions are now using
larger values.  This controls the maximum size procedure you can
compile.

Please report any problems you find.

To bootstrap the KA version from the KI version, the following
modules need to be replaced in the KI version of PASLIB (by
KA versions of the modules):  PASIO, DEBUG, PARSE, and PASNUM.