Oppolzer - Informatik / Stanford Pascal Compiler

Making CSP numbers consistent between PASCAL1, PASCAL2 and PASMONN

When I did some maintenance to PASCAL2 (the P-Code translator, which translates P-Code to 370 machine code), I discovered that the internal numbers of the standard procedures (P-Code identifier = CSP) were totally different between the two compiler passes.

The compiler (first pass) defined the CSPs as a subrange type (0 .. NSPROC) and the second pass as a scalar type (CSPTYPE), and the sequence of the CSPs was different. There was no correlation between the numbers of the first pass and the sequence in the scalar type of the second pass. This was very disturbing.

The communication between the two passes goes through the P-Code file; the CSP instruction has the CSP name as parameter (e.g. CSP WLN for WRITELN). When the second pass reads the CSP instruction, it translates the CSP name to its internal representation (the scalar type), which is different from that of the first pass.

There is a strong linkage between the second pass and the PASMONN run time system; the second pass generates code involving the CSP number, when calling a CSP. The CSP number is used as an index to a branch table in PASMONN. So if the CSP numbers are changed, PASMONN and its branch table (see entry $PASCSP) will have to be changed, too

When I first tried to change the CSP sequence in October 2016, this ended up in a big disaster, because it is not sufficient to change PASMONN and PASCAL2 in sync. After you change PASMONN, you need to recompile everything, because all your existing TEXT files are invalid, but you have no valid compiler to do this, and PASCAL2 (which is worse) would need a compile by the new version of PASCAL2 ...

So I first had no idea how to do this.

Then, in November, I had the idea: PASMONN needs a second entry besides $PASCSP, which supports the new CSPTYPE, that is: a second branch table. I did the following changes:

• new entry $PASCSP2 in PASMONN, which uses a different branch table, according to the new CSPTYPE in PASCAL2. $PASCSP2 then branches to the subfunctions of $PASCSP

• PASCAL2 uses the new CSPTYPE and generates calls to $PASCSP2 instead of $PASCSP

• so the "old" TEXT files stay valid, and the transition to the new compiler's output is no problem

• I furthermore changed PASCAL1, so that the CSP type is not a subrange of integer any more, but the same scalar CSPTYPE as in PASCAL2

• in fact: not exactly the same, because there are some CSPs that are only known to PASCAL2. I decided that it would be best to put those CSPs at the beginning of the CSP scalar type in PASCAL2, so now we have 10 CSP numbers at the beginning of the scalar type in PASCAL2, which are PASCAL2-only (only one is in use at this time, 9 are reserved), and each CSP number x of PASCAL1 is x + 10 in PASCAL2. New CSPs should be added at the end of the CSPTYPE (same name in both passes).

This is the CSPTYPE definition of PASCAL2:

CSPTYPE = ( PCTR , PN01 , PN02 , PN03 , PN04 , PN05 , PN06 , PN07 , PN08 , PN09 , PPAG , PGET , PPUT , PRES , PREW , PRDC , PWRI , PWRE , PWRR , PWRC , PWRS , PWRX , PRDB , PWRB , PRDR , PRDH , PRDY , PEOL , PEOT , PRDD , PWRD , PCLK , PWLN , PRLN , PRDI , PEOF , PELN , PRDS , PTRP , PXIT , PFDF , PSIO , PEIO , PMSG , PSKP , PLIM , PTRA , PWRP , UNDEF_CSP ) ;

BTW: I don't want to add new CSPs if not absolutely necessary. If new runtime functions are needed, I usually try to code them in Pascal and add them using the new library module mechanism; see other subpages (examples: ALLOC, FREE, MEMCPY, MEMSET etc.).