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