Oppolzer - Informatik / Stanford Pascal Compiler


Home       Lebenslauf       Schwerpunkte       Kenntnisse       Seminare       Kunden       Projekte       Produkte       Blog       Stanford Pascal       Kontakt

The Stanford Pascal Compiler / Evolution Steps

Back to Compiler main page

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:

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

Back to Compiler main page