This file describes the files used in the "new" Pascal-20, i.e. the version that does not depend upon the Pascal-10 compiler and runtimes. Note that the compiler source files (pascmp.pas, as well as the temporary passcn.mac and paslnk.mac) are still more or less the same as the corresponding files for Pascal-10. This will be kept that way as much as possible. There are now versions of Pascal for all combinations of the operating systems Tops-20, Tops-10, and Tenex, and the hardware KL-10, KI-10, and KA-10. (The Tenex versions have a few minor features missing.) This file describes the Tops-20 version. If you are a Tenex site, this file is also applicable to you, but you should also have received a small save set containing binaries for Tenex and a file TENEX.OPR explaining a few oddities of the Tenex implementation. The sources for Tenex are the same as for Tops-20. If you are a Tops-10 site, you should have received a completely different distribution from this one. Although the compiler itself runs in native mode, it uses SCN7B (the standard Tops-10 command scanner) to scan the command line. This will be replaced when DEC comes up with a standard for Tops-20 compilers. Until then, the EXEC expects to be communicating with a Tops-10 compiler, so we use the Tops-10 scanner. SCN7B uses the emulator, but a RESET JSYS is done to clear emulation mode before the compiler itself is started. Note that the command scanner is precisely the same as that used by Fortran-10, so the EXEC should be modified to pass commands as it does for Fortran-10. (In particular, LINK should be called by /RUN:LINK, rather than LINK!) If you do not choose to have Pascal interface with the EXEC, there is a completely native mode command scanner that will rescan the command line and supply most of the facilities of the EXEC. See below. Note that the memory structure of Pascal-10 and Pascal-20 programs is slightly different. The two compilers are as compatible as possible at the source code level, but the .rel files should be used only on the machine for which they were compiled, and they should be loaded with the proper runtimes. A Tops-10 core image (.EXE file) can be executed on Tops-20 under the emulator, if it was produced by edit 74 or later of the Tops-10 compiler. This export does not usually include the Tops-10 compiler. Should you wish to produce a compiler that compiles code to run on Tops-10, you should edit pasprm.pas to set the appropriate switches and then recompile. To produce a compiler that compiles code for Tops-20 and runs on the 10, you must start with the Tops-10 compiler and runtimes and recompile them on a PDP-10 with modified pasprm.pas. I.e. the compilers can each compile code for either machine, if the appropriate switches are set in pasprm.pas. The distributed version assumes that the Pascal runtime library is sys:paslib.rel. This can be changed by editing pasprm.pas and recompiling, or by clever use of Filddt. (The strings "SYS " and "PASLIB " are stored in Ascii in the compiler.) ***********compiler*********** Compiler source files. (.rel files may or may not appear in your distribution.) pascmp.pas - main compiler source. (identical to the tops-10 source, except that the extended lookup arguments have been commented out in reset and rewrites in the startup code.) pasprm.pas - parameter file "required" by pascmp. Sets up operating system and site dependent options. If this is changed you must recompile pascmp.pas and then reload. paslnk.mac - low-level compiler routines passcn.mac - compiler link to SCN7B, which is currently used to scan the command line. Note that paslnk and passcn are temporary modules, until DEC allows us to supply a real Tops-20 command scanner. The compilation process assumes that you have the following .unv files: Pascal-20: pasunv.unv Tops-10 (until paslnk and passcn are replaced): c.unv, scnmac.unv Tops-20 (normally on sys: at all Tops-20 sites): monsym.unv The loading process assumes that you have the following standard Tops-10 modules (also part of the temporary command scanner): helper.rel, scn7b.rel These auxilliary files are all included in the distribution, except for monsym.unv, which we assume you have. A file pascal.ccl is included. It is an indirect command file for LINK to load the compiler. To create a new compiler, compile PASCMP.PAS with the current pascal, and then do @LINK *@PASCMP */G @SAVE PASCAL If PASLIB is not on SYS: yet, you will also have to do *PASLIB/SEA No D command is needed at the moment. If you don't want to recompile the compiler, all you really need is the thing itself, which is pascal.exe - Pascal-20 compiler ********compiler for those not adding PASCAL to the EXEC******** For those who do not want to add PASCAL as a known language, there is an alternate command scanner that does not require the use of the EXEC. The files are: paslnx.pas - the scanner itself, sort of equivalent to passcn.mac paslny.mac - a few MACRO support routines, sort of equivalent to paslnk.mac pas.ccl - an indirect file to LINK to load this. I recommend saving it as PAS.EXE, to save typing. This command file also assumes that PASLIB.REL is on SYS:. If not you will have to mention PASLIB/SEA to LINK. Two other general packages are used by paslnx.pas. The .MAC files are the source for the package, the .PAS files are designed to be INCLUDE'd. pascmd.mac,pascmd.pas - a general-purpose comnd jsys interface string.mac,string.pas - the (unimpressive) beginning of a set of runtimes to do string manipulations on packed array of char. This uses ADJBP, so Tenex people would have to convert them. They are not used in the Tenex version at this time. The same compiler source and .REL file is used: only the command scanner is changed. If you say PAS, you will get a native-mode scanner with the same switches as documented in the manual. However instead of REL,LST=SOURCE, it will want just a source file name. It will produce a .REL file by default. You can suppress the .REL file by /NOBIN, and cause a listing file to be created by any listing switch (/LIST, /CREF, or /OBJECTLIST). The scanner rescans the command line, and in this mode simulates the EXEC's EXECUTE and DEBUG commands. PAS TEST is equivalent to EXEC TEST.PAS PAS TEST/DEBUG is equivalent to DEBUG TEST.PAS PAS TEST/LOAD is equivalent to LOAD TEST.PAS PAS TEST/NOLOAD is equivalent to COMPILE TEST.PAS The same conventions about not recompiling if there is already a .REL file, etc. are followed. /COMPILE forces compilation even if the dates don't compare. All normal compiler switches are also allowed. The .REL and .LST files, if any, use the same name as the source file (truncated to 6 characters if necessary), on the connected directory. Note that there is a possible confusion about /DEBUG and /NODEBUG. In the normal compiler, we have two orthogonal decisons: debug code compiled? YES /DEBUG (default) NO /NODEBUG debugger actually used? YES EXEC DEBUG command NO EXEC EXECUTE command In this version, since the EXEC is not involved, it is all done with the /DEBUG and /NODEBUG switches: debugger actually used? YES NO debug code YES /DEBUG default compiled? NO impossible /NODEBUG *******EXEC linkage******** exec.pat - instructions on how to patch the EXEC to link to PASCALL. This file assumes that you do not have sources, and thus tells you how to make the patch in FILDDT. It does not assume very much knowlege of DDT, at least to do the easiest version of the options. exec.ddt - the EXEC patches themselves. See exec.pat first. The files EXEC.PAT and EXEC.DDT depend upon which release of the EXEC you are using. Here are the currently available versions of the files: release EXEC.PAT EXEC.DDT 3 and 3A EXEC3.PAT FILDDT.DDT 4 EXEC4.PAT EXEC4.DDT *******runtimes******** The runtime sources are the following. (Note that pasunv.mac compiles into pasunv.unv, which is also needed by the compiler sources.) pasunv.mac - symbols used by all runtimes pasio.mac - I/O runtimes (modules pasio and danger) pasnum.mac - I/O conversion routines passtr.mac - I/O to/from strings pasddt.mac - low-level routines for pasddt (module debsup) pascnv.mac - misc. sixbit conversion, etc. pasdat.mac - date/time routines (replaces routines from the Fortran library used in the 10 version, since they use UUO's, and we can't tolerate having the emulator called) paspsi.mac - interrupt handling routines heap.mac - new and dispose used when DISPOSE is called debug.pas - pasddt There things are all put together with maklib to form a library, which you should certainly take (and just replace single modules when you recompile). However pasddt.rel should not be linked into the library. Instead it should be put on sys: as pasddt.rel. Loading it will cause things to be set up so that you get a debug. (Otherwise there is no way to control when pasddt gets loaded.) Should you not wish to recompile, simply put the following on sys: paslib.rel - runtime library for Pascal-20 pasddt.rel - pasddt extern.pas should be put somewhere where users can read it. It contains declarations for external procedures not built into the compiler (as described in the manual). *******Details for numerical hackers********** There is a problem with programs that use Fortran subroutines: If an error occurs, Fortran will call its error processor, which will print an error message using TTCALL's. This will invoke the emulator, and the next time Pascal tries to expand core, the emulator will stomp on your program (ill mem ref). I have no good solution at the moment. However I am including a copy of FORDUM.MAC, the fortran error processor, which has been "nativized", i.e. made native mode. You can load this explicitly as part of your core image, put it in FORLIB instead of the version DEC supplies (using MAKLIB), or add the code to PASIO.MAC so it is always loaded. The advantages of the various methods are: adding it to PASIO.MAC - it is there when you need it, and you do not have to change FORLIB putting it in FORLIB - you do not get it for programs that don't use Fortran subroutines. Note that FORLIB is constructed in such a way that FORDUM is not loaded with real Fortran programs. It is strictly a dummy module for use when Fortran routines such as SIN and COS are called by other languages, as in this case. Since other languages (e.g. SAIL) have the same problem with the emulator, it seems reasonable to always use the nativized Fordum. It should act precisely the same as DEC's, but just not invoke the emulator. So we strongly recommend replacing DEC's version of FORDUM with ours in FORLIB, until they make Fortran be native mode. At that time the problem should go away. maklib forlib=forlib/master:fordum,fordum/replace:fordum loading it explicitly - you do not get it for programs that don't use Fortran subroutines, and you do not have to change FORLIB As far as I can tell, this FORDUM should act exactly the same as DEC's, and would even work with real Fortran programs. However it has not been tested very much. I recommend putting it in FORLIB. We have had some requests for more friendly handling of arithmetic errors (e.g. divide by zero, floating underflow). At the moment we print an error message and bomb the program. I still believe that is the correct thing to do unless the user specifically has designed his program to take errors into account. However for those having special need, I have included two files with procedures designed to be set up as interrupt handlers for arithmetic exceptions. ZEROVR.MAC simply zeros the result and goes on. CALFOR.MAC actually invokes the Fortran arithmetic exception handler. See the extensive comments at the beginning of ZEROVR.MAC for a discussion of the issues involved in handling arithmetic error. In those comments a 5 line macro program is given to allow you to test explicitly whether an error has happened from the Pascal program, and have the program recover for itself. I strongly recommend that style of operation, rather than setting up interrupts. NB: CALFOR and ZEROVR currently use KL instructions (DMOVEx, ADJSP, and ADJBP), so they should be converted if anyone on Tenex wants them. This is a very easy job, but one that I don't have time for at the moment. *******Random packages******* These things will probably be put in PASLIB when they have been tested. They use KL op codes, but they are only relevant for Tops-20 anyway, so this should cause trouble for Tenex people. PASCMD.MAC, PASCMD.PAS - complete support for the COMND jsys. PASCMD.PAS has the declarations in it, and is designed to be INCLUDE'd. It also has the documentation as comments. PASPTY.MAC - two routines for openning PTY's. Includes documentation. Just helps you get and open PTY's. You still have to do your own timing. FORTIO.MAC contains routines to allow you to call fortran subroutines that do Fortran I/O. It should be self-explanatory. It has not gotten much testing, but the current state will at least provide some advice to system programmers who have to do this in a serious way. When DEC comes out with native-mode Fortran, the interface will probably change. The code that will most likely change is under a conditional, KLUDGE. Also, it is possible that something will have to be done about JSP RESET.+1 The idea is that we need all of that routine except the RESET UUO itself, which is the first instruction. If the 20 version begins with a RESET jsys, then RESET.+1 will still be the right entry point. If not, some better mechanism may be needed. 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 not 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 should load this with PFORMS.MAC, which contains some system-dependent subroutines. Currently PFORM is supported on Tenex only if you have PA2050. PASSRT.MAC is an interface to DEC's SORT/MERGE. Version 4 of SORT is required. Docmentation is at the beginning of PASSRT.MAC. *******Documentation******** The manual is produced using an old version of Brian Reid's SCRIBE system. This allows automatic production of crossreferences, tables of contents, etc. The files involved are the following: pascal.mss - the "manuscript" file (i.e. the main source file) pascal.aux - table of crossreferences (produced by the previous run of Scribe - should always be kept around for use by future compilations) pascal.doc - the final manual As I mentioned above, the version of SCRIBE we used for this manual is an old one, produced before Brian became as serious about it as he is now. He has now made it into a serious product, and it is being marketed by Unilogic, Inc. The version included here is far out of date compared to what is currently being distributed, and includes only the one document type and device type needed to make this manual. If you like what you see, we encourage you to get the real thing from Unilogic: Unilogic, Inc. 605 Devonshire St. Pittsburgh, Pa. 15213 In addition to the program, documentation, reference cards, and a collection of other document types are available. The files included in this distribution are: scribe.exe - The scribe program. Assumes the data base is on DSK:. You would normally have a directory, but this one is set up for dsk:. (It can be changed by depositing 1,,1 in location 140 and starting scribe.) file.dev - definitions for the "device" file, i.e. for producing .DOC files. crt.tfo - characteristics of the character set assumed available. An alternate manual is also included. It does not describe all of the more abstruse features, but should be much easier to understand. It is designed to be compiled with the current version of Scribe, though the version included here can probably be used with some small amount of work. The files are PASCAL-MEM.MSS - source PASCAL-MEM.DOC - the document It is intended that this document should be called PASCAL.MEM when it is finally put on your system.