Origins
Several years ago I wrote a Pascal compiler. The motivation was simple: as a teenager, I had learnt from my first programming textbooks that a compiler is a very sophisticated thing. This claim eventually became a challenge and required to be tested by experience.
ha.art.pl
First, a simplistic PL/0 compiler came into being, and later an almost fully-functional Pascal compiler for MS-DOS has grown from it. My source of inspiration was the Compiler Construction book by Niklaus Wirth, the inventor of the Pascal language. I don't care if Wirth's views are now considered obsolete and have no direct connections to the IT mainstream, or if the compiler design fashion has changed. It is enough to know that his techniques are still simple, elegant, and — last but not least — bring much fun, since it is more appealing to parse a program source with a handwritten recursive descent parser and generate the machine code, rather than to call yaccs, bisons and all their descendants.
My compiler's fate was not so trivial. It has lived two lives: the first one in my own hands, and the second in the hands of computer antiquarians from Poland.
XD Pascal
My newborn compiler was named XD Pascal. It supported all Pascal statements except goto and with. The former seemed to be difficult to implement, since it would destroy the perfectly hierarchical program structure. The latter could make the simple scope rules ambiguous.
All main data types were also supported. Beyond the scope were only the unsigned integers, sets, enumerations and variant records — but all these are obviously not the daily necessities. Nevertheless, I could not deny myself the pleasure of introducing floating-point numbers and the 8087 FPU arithmetic — that was the impact of my professional addiction to engineering computations.
When implementing procedures and functions, I was afraid that the recursion and the storage of local variables on the stack would be a big problem. However, a real, Pascal-specific difficulty was with the nested subroutines. One can have an innocent desire to access an outer subroutines's local variable from within the inner one. However, the inner subroutine does not have the stack frame address for the outer one, in other words, it does not know what origin to use with the variable offset. This address is to be passed to the inner subroutine as an additional hidden argument. I suppose that it was this difficulty that forced the designers of C to completely abandon the nesting of subroutines. But Pascal still has them, and this feature cannot be ignored.
The code generator created the simplest COM executables for real-mode MS-DOS. Machine instructions were generated directly, without any external assembler or linker. I used 32-bit registers for data, but the addressing remained 16-bit (a segment/offset pair).
The memory model was similar to the 'small' one (if someone still remembers this 16-bit era terminology): the code, data, and stack occupied one 64 kbyte segment each.
Memory usage
Generating EXEs and switching the segments on the fly seemed to be too hard, and the tight limitations of the 'small' model forced me to say goodbye to the self-compilation. Certainly I saw some self-compiling compilers whose code fit well within just one segment (e.g., Context). However, they rarely could do anything useful besides this ability to compile themselves. Instead, I wished to make my compiler suitable for numerical computations and graphics. That's why I included, among other examples, the fractals, the Gauss method for solving linear equations, the fast Fourier transform, and even the Kalman filter for estimating the inertial navigation system errors.
Mandelbrot set fragment
Fast Fourier transform
Inertial navigation system error estimation
What I eventually got was very similar to the ancient Turbo Pascal 3.0 (without OOP) and the amateur BeRo Tiny Pascal. The author of the latter has managed to self-compile it under Windows, but sacrificed floating-point arithmetic and many subtleties of the grammar, which I wished to preserve. Among more modern features, my XD Pascal got the Delphi-style single-line comments (//) and the Result variable.
Nevertheless, since its birth, my compiler was marked for death. Pascal was irreversibly going out of fashion, and MS-DOS had become archaic long before. On a day when I switched from a 32-bit Windows XP to a 64-bit Windows 7 with no DOS virtual machine, I considered my project dead.
Revival
Then something strange has happened. After three years of oblivion, a team of Polish retrocomputing enthusiasts and Atari fans has found my compiler. It seems that they didn't care much about abstract problems like self-compilation or grammar strictness. They simply needed a convenient programming tool for their favorite machine. Using my project, they constructed their own Mad Pascal compiler for the 6502 architecture. The language grammar was expanded, the support was added for separate units with the interface and implementation sections, the goto statement, unsigned integers, sets and enumerations, inline assembly code. Instead of the machine code, the assembly code was generated. It was then translated by a homebrew assembler.
The external appearance of the language became significantly closer to the de-facto standard Pascal. The compiler internals look somewhat horrific, the reserved words are mixed with the names of standard subroutines, but this doesn't disturb the developers. Whatever it looks like, the endeavor is surprisingly viable: for three years Mad Pascal has been regularly updated, many games are written in it, the authors annually attend the Silly Venture retrocomputing conference (the link may require VPN). It seems that Atari traditions are very strong in Poland.
An event noticeable for the Polish fans of Atari happened in Spring 2018: the book Robbo. Solucja (Robbo. Walkthrough), an example of experimental literature, was published. I need to emphasize here that the Robbo game for Atari, which was published 30 years ago, still excites the older Polish fans and fills them with a kind of patriotic delight. Generally speaking, it is not surprising that there appeared a book inspired by the game. But the funny fact is that 60 percent of the book, as the authors say, is the walkthrough tutorial generated by the Atari computer itself. The text generation program is written in Mad Pascal.
graczpospolita.pl
It looks like some people consider the book as a great example of contemporary art:
It would be misleading to treat this book just as a collector's item for Robbo fans, or, more generally, Atari fans. We deal with a rare example of the interaction between the video game culture and literature (in this case, electronic literature), where the starting point is the 'game', not 'literature'. For some, it is meaningless 'art for art's sake'. For others, such a crossover offers absolutely new opportunities and experience. Nothing prevents you from creating a version of Robbo that you can finish using the 'walkthrough' from the book. The book fits well with my view of the video games as art. Art, in which the player can be both the recipient and the creator — if during the 'game' there is an 'audience' watching the player creating his own 'game' history. The content of the book can be adapted to a performance show with an actor playing Robbo using the elements of the 'walkthrough' from the book. In order not to remain groundless: the performance based on Robbo. Solucja took place on May 11, 2018 in the Bunker contemporary art gallery in Krakow, during the presentation of the book accompanying the Inexhaustibility exhibition.
A performance show in Krakow. It is worth having written a compiler.
Автор: Tereshkov
