Oppolzer - Informatik / Stanford Pascal Compiler

Porting Stanford Pascal to Windows, OS/2 and Linux - success !!

In December 2016, I finally reached my target from 2012: porting the compiler to Windows, Linux and OS/2. This turned out to be pretty useful, because from now on the turnaround times for changes to the compiler became much lower. And: the other tools that I use, especially PASFORM.PAS (which formats Pascal sources) run on Windows etc., too, now, so that I don't need switch platforms that often.

This is the compiler compiling itself (and the P-Code translator) on Windows (you may notice, that the version date changed on the second run, because the compiler compiled itself and then the new compiler was used to compile the P-Code translator):

PCINT (Build 1.0 Dec 30 2016 20:41:29) **** STANFORD PASCAL COMPILER, OPPOLZER VERSION OF 12.2016 **** WARNING: PASCAL EXTENSIONS USED. **** NO SYNTAX ERROR(S) DETECTED. **** 13636 LINE(S) READ, 144 PROCEDURE(S) COMPILED, **** 23534 P_INSTRUCTIONS GENERATED, 2.30 SECONDS IN COMPILATION. *** EXIT Aufruf mit Parameter = 0 *** *** Pascal Programm STP *** PCINT (Build 1.0 Dec 30 2016 20:41:29) **** STANFORD PASCAL COMPILER, OPPOLZER VERSION OF 01.2017 **** WARNING: PASCAL EXTENSIONS USED. **** NO SYNTAX ERROR(S) DETECTED. **** 11437 LINE(S) READ, 84 PROCEDURE(S) COMPILED, **** 25297 P_INSTRUCTIONS GENERATED, 2.06 SECONDS IN COMPILATION. *** EXIT Aufruf mit Parameter = 0 *** *** Pascal Programm STP ***

Look at the performance; it is pretty amazing. And recall that the compiler is not running on the hardware directly; instead the P-Code instructions are (kind of) interpreted.

There were some interesting milestones when testing more programs on the Non-mainframe platforms:

• some problems with sets of char; the internal representation still had some dependencies of the character set (e.g. MAXVALUE of a char set constant) - but this is now solved

• some features were still missing on Windows, for example binary files (files that are no TEXT files); long branches (branches to another block); linking of modules during PRR compile stage etc. - this has been added in the meantime

• when testing some programs, I decided to provide a new standard type VOIDPTR (this is a type that is compatible to every other pointer type, an "untyped" pointer type; it is now predefined)

• and: I decided that it would be convenient to support hex integer constants in a C like syntax: 0xabcd for example

• the compiler still complained on char string compares when lengths didn't match (constant string to be compared shorter than char array); the compiler now expands the constant string automatically by appending blanks

• PASSNAP doesn't work at the moment on the Non-Mainframe platforms, because PASSNAP uses knowledge about the Mainframe implementation (save area layout etc.); there should be another variant of PASSNAP which is adopted to the PCINT interpreter and it's internal structure - this has still to be done

• and: there may still be some features missing (some P-Codes or CSPs unimplemented); I will implement them as soon as I discover them - one which I know already: when using ALLOC etc, there is a call to PASSYS$ to do the basic system alloc function (aka GETMAIN), but the PCINT interpreter issues a BADBRANCH runtime error.

BTW: I decided to make the compiler and the P-Code translator available on this website (see Resources page), but not the PCINT interpreter. This is because it is not perfect yet, because I invested very much in this part of software which I created from scratch, and because I want to know who is using the compiler on the Non-mainframe platforms - and probably support you, if you plan to do so. So, please, if you plan to use the compiler on Non-mainframe platforms like Windows, OS/2 or Linux, contact me by eMail etc., so that we can talk about a test license (which will be free of charge, for the moment).