README

Fans of John LeCarre may think of this as being "The Looking Glass War" version of a compiler development project. Though unlike the protaganists in that novel, so far no sinister plots have led to this ancient compiler writer being harmed.

Once upon a time a company called Oregon Software developed and sold a suite of optimizing compiler products based on compiler techology that I (Don Baccus) began developing around 1977.

While originally developed as a suite of Pascal compilers, These eventually grew to include compiler front ends for Modula-2 and C/C++ as well.

We targeted the PDP-11 for our first version, and eventually also targeted and sold products for the VAX, X86, M68000, SPARC, and NS32000 architectures.

We also contracted with Honeywell to create a version for their DPS6 minicomputers (the 32-bit version perhaps as it was 1980 or 1981), for their internal use.

We hosted compilers on a large variety of operating systems. On the PDP-11 this included RT-11, RSX-11, and RSTS/E. On other computers we supported operating systems including VMS, MSDOS, VersaDOS, and a wide variety of BSD- and Bell-based Unix ports (there was no Linux way back then).

We also provided cross compilers for some environments.

Why was it named Pascal-2? We originally had written a PDP-11 Pascal compiler in assembly code (OMSI Pascal) which was then used to bootstrap the new technology (OMSI, then later Oregon Software, Pascal-2).

Our original Pascal-1 for the PDP-11, written in PDP-11 assembly code, was widely considered to generate decent code by the standards of the day. Code generated by Pascal-2 for the PDP-11 was about 40% shorter, on average, than code generated by Pascal-1 for meaningful programs, and to be honest no native PDP-11 compiler could touch it. The people implementing MicroPower Pascal at DEC ran some tests comparing Bliss-11 to Pascal-2. Bliss beat Pascal-2 by about 10% in space and speed. Of course, due to memory needs, Bliss-11 only ran as a cross-compiler on VAX/VMS, and the code they tested leaned very heavily on low-level Bliss features and was mature, supported product code, so they were very happy with the result of a simple port to our Pascal environment being compiled on a PDP-11.

Binaries for the RSX PDP-11 version of Pascal-2 can be found, but there are no sources.

Unfortunately it long seemed that source code for all of the compiler products no longer existed. The Pascal, Modula-2 and C/C++ frontends seemed to no longer exist, nor the optimizer and none of the code generators.

As the person who wrote the Pascal-2 and the first version of the Modula-2 front ends, and most of the PDP-11, VAX, M68000, and SPARC code generators, and the original optimizer, this saddened me.

But amazingly an old customer saw my name pop up in a discussion of old PDP-11 and M68K compilers, and had access to sources that an old company had purchased long, long ago and sent a copy along to me.

Only sources for the Pascal compiler, some utilities, and part of the library (written in M68K assembly and Pascal) were included in the sources I was gifted.

In my git account you can see those unmodified sources in the mc68000_pascal_2 repository.

The code in this repository here is based on our VAX/VMS-hosted M68000 cross-compiler. It has been rehosted to compile and run with Free Pascal, and includes the original M68K code generator, and a partial implementation of an AARCH64 code generator and simplified and incomplete library.

At present it's working well enough run the 3500 line Pascal formatting utility we provided, and that's not all that bad a tool. There's also a cheesy program to generated a cross-reference listing of identifiers used by a program which was useful enough back in the day where lots of upper case characters were the norm in many environments. These run with or without runtime error checking enabled.

And, since writing the above, it now can run the original VMS->M68K cross compiler, rehosted as a Linux/Darwin AARCH64->M68K cross compiler.

The generated code ranges from decent to fairly bad so far. Getting things working has been my priority. In particular register allocation in the code generator is simple and, well, relatively crappy.

It's still decent enough to beat Free Pascal, using that compiler's O3 optimization level, in various computationally bound integer-based benchmarks.

Currently no floating point operations are supported though adding it will be simple enough, just a bit tedious, as the instruction set is similar in structure to the regular instruction set.

There are scary copyright statements in the source. As the majority owner of Oregon Software while it existed, and primary author of the technology, I'm not too worried about suing myself for putting them up here for public viewing. I may switch sources over to the GPL.

Some notes on the structure:

The compiler originally ran on computers as small as a PDP-11 running RT-11 with a maximum of 56KB RAM available. Yes, KB, not MB much less GB. And it could compile itself in that environment with only two 8" floppy disks for mass storage. This compiler was the basis of DEC's MicroPower Pascal and their RSX-11 Pascal. The machine described above, compiling the compiler itself at 100 lines per minute (ouch, but hey, floppy disks), was part of the acceptance terms of our contract with DEC/Digital. Slow! While we met the goal, DEC realized that this was stupid and only supported compiling MicroPower Pascal programs on PDP-11s with at least one reasonably-sized hard drive.

To make this possible, the compiler is split up into several physical pieces.

Architecturally it is a two-pass compiler. First pass consists of a lexical scanner and syntactic/sematic parser. The second pass consisted of an optimizer and code generator working on one procedure at a time.

The parser is a recursive descent parser, and there was a period of time where old farts like me were considered foolish dinosaurs for not embracing "compiler-compiler" technology like YACC or, nowadays, BISON, which generate LALR(1) parsers. I've lived long enough to see the pendulum swing back and frankly, I feel somewhat vindicated. Clang, Rust, and Swift are current, popular compiler front ends that use hand-written recursive descent parsers and the reasons are the same that caused me to stubbornly support that tecnology long after so many had switched to YACC/BISON style parser generators.

As to why, the Clang people have had some things to say about the decision over the years.

Back to this compiler technology, on a small computer it was configured to run in four passes, and each pass consisted of overlays that were swapped in from disk. Data structures such as the symbol table, parse tree, and the like were cached on disk using an LRU approach. If the environment included enough RAM, the compiler could be statically configured to keep all necessary data in RAM along with the executable code without need for overlays or data caching.

So if you do dare to dig in, you'll see a lot of code conditionalized by "if bigcompiler" (all data stored in memory), "if needcaching", "if scanalys" and "if travcode" (number of passes) and the like. I'm slowly ripping that out of the Free Pascal-hosted version but the original VMS->M68K cross compiler sources give some idea of the effort required to support a wide range of computers back in those days. It wasn't nearly as much fun as it might seem when casually looking over the code.

Others made significant contributions over time, including Michael S. Ball who wrote the C/C++ front end, and the changes required to the optimizer and code generators to support it, with some help from me, though there were surprisingly few changes required. Oregon Software hired a compiler writer from Sun to productize the Modula-2 work I had done, and while I was still running Oregon Software we licensed Gordon Bell's Encore computer company to port it to the NS32K architecture. As part of that effort a very bright compiler guy named Steve, whose last name I don't remember, sat down with me and we planned out extensive improvements to the optimizing phase, which he then implemented. Things that were happy to devour memory which was becoming cheaper and cheaper, with no concerns about supporting cramped 16-bit architectures like the PDP-11.

And there are parts of the compiler that just make me groan and want to hide rather than make this public. Many of the worst warts stem from the early days of needing to host the compilers on PDP-11s, in particular RT-11 boxes with no I/D space separation, the I/O page eating up 8KB of the memory available to programs (though this made writing device drivers in Pascal easy, using our "interrupt procedure" extension to write interrupt handlers and the ability to "origin" variables at interrupt vector addresses and device registers). Anyway, compromises with sanity were made in order to make things fit, and while the overall architecture has stood up well enough, there are some very ugly bits.