My compiler Pascal and Polish modern art


A few years ago I wrote the Pascal compiler. The motivation was simple: in my youth I learned from my first books on programming that the compiler is an extremely complex thing. This statement was stuck in a brain and ultimately demanded an experimental test.


First, the simplest PL / 0 compiler was born , and the almost full-featured Pascal compiler for MS-DOS gradually grew out of it. I was inspired by the book Compiler Construction , written by the creator of the language Pascal Nicklaus Wirth. And let the views of Wirth are already outdated and have lost all connection with the realities of IT, and the compilers do not quite the way Wirth taught. However, his methods are still simple, elegant, and most importantly - bring joyAfter all, it is much more tempting to self-disassemble the program text by recursive descent and generate machine code than to call on yaks , bison and all their successors for help .

The fate of my compiler was not the most trivial. He lived two lives: the first is in my hands, the second in the hands of Polish connoisseurs of computer antiquities.

XD Pascal

My freshly baked compiler is called XD Pascal . He supported all operators of Pascal, except gotoand with. The first one seemed to me difficult to implement, since it destroyed the ideally hierarchical structure of the program. The second created confusion with the areas of visibility of names.

All major data types were also supported. Only unsigned integers, sets, enumerations, and variant entries are left out of the box - but these are clearly not essential items. Nevertheless, I could not deny myself the pleasure of floating-point numbers and their arithmetic on the 8087 coprocessor - this was affected by a professional propensity for engineering calculations.

When implementing procedures and functions, I was afraid that recursion and storing local variables on the stack would be a big problem. However, the real difficulty specific to Pascal lurked in a completely different place - in working with nested procedures. A completely innocent need may arise to refer to a local variable of an external procedure from an internal one. However, in the internal procedure there is no address of the stack frame of the external procedure - the internal procedure does not know what the address of the desired variable is counted from. This address must be transferred to the internal procedure every time through an additional hidden parameter. I suspect that it was precisely this complication that caused C developers to completely abandon the embedding of functions. However, they are in Pascal, and this has to be considered.

The code generator created the simplest COM executables for real MS-DOS mode. The machine code was generated directly, without the help of an external assembler or linker. For data, I used the 32-bit registers of the 80386 architecture, and the addressing remained 16-bit, as a segment-offset pair.

The memory model approximately corresponded to the “small” one (if someone else remembers this terminology of the 16-bit era): for the code, the global data and the stack, one segment of 64 kb was allocated.

Memory Usage

Generating EXE files and switching segments on the fly seemed too complicated, and the tight framework of the “small” model made me say goodbye to the idea of ​​self-compilation. Of course, I encountered self-compiled compilers whose code completely fit in one segment (for example,Context ). However, they rarely knew how to do anything useful other than this self-compilation. I wanted to make my compiler at least a little suitable for numerical calculations and graphics output. Therefore, among the examples of programs appeared fractals, the solution of linear equations according to Gauss, the fast Fourier transform, and even the Kalman filter estimation of errors of an inertial navigation system.

A fragment of the Mandelbrot set

Fast Fourier transform

Estimation of errors of an inertial navigation system

What I got as a result, most of all resembled ancient as the world of Turbo Pascal 3.0 (still without OOP) and amateur BeRo Tiny Pascal. The author of the latter has mastered self-compilation under Windows, but he sacrificed floating-point arithmetic and many grammar subtleties that I wanted to observe. Of the more advanced features in my XD Pascal, single-line comments ( //) and auto- variable, borrowed from Delphi, appeared Result.

However, since my birth my compiler has been marked with the seal of death. Pascal has already irreversibly gone out of fashion, and MS-DOS has long become archaic. That day, when I switched from 32-bit Windows XP to 64-bit Windows 7 without a DOS virtual machine, I mentally buried my project.


Then a strange thing happened. After three years of complete oblivion, a certain group of Polish retrocomputing enthusiasts and fans of Atari found my compiler. Apparently, the abstract problems of self-compilability and strictness in the implementation of grammar worried them a little. They just needed a handy programming tool for their favorite car. From my project, they made their own Mad Pascal compiler for architecture 6502. The grammar of the language has grown, there is support for modules with sections of the interface and implementation, operator goto, unsigned integers, sets and enumerations, assembler inserts. Instead of machine code, assembler code was now generated. His final broadcast was made by an assembler of his own design.

Externally, the language has become much closer to the actual standard of Pascal. Inside, the compiler looks somewhat frightening, the reserved words are mixed with the names of standard procedures, but this does not bother the authors at all. No matter how it looks, but the case turned out to be surprisingly tenacious: Mad Pascal has been regularly updated for three years, many games have been written on it, the authors annually speak at Silly Venture retroconference (link requires VPN). There is a feeling that the traditions of honoring Atari are very strong in Poland.

In the spring of 2018, an event occurred that was quite remarkable for the Polish crowd of Atari fans: the book “Robbo. Solucja " (" Robbo. Passage ") in the genre of experimental literature. Here it must be said that the game Robbo for Atari, published 30 years ago, still excites the hearts of the older generation of Poles and fills them with patriotic enthusiasm. In general, it is not surprising that a book about the game appeared. The only funny thing is that according to the authors, it consists of 60% of the instructions for passing the game, generated by the Atari computer itself. The generation program is written on the very Mad Pascal.


And it seems that some perceived the book as a worthy example of modern art:
It would be wrong to treat the book only as a collectible for Robbo fans or, more generally, for Atari fans. We have to deal with a rare case of the clash of the culture of video games with literature (in this case, electronic), when the starting point is "game" and not "literature." For some, it is meaningless art for the sake of art. For others, such a crossing carries entirely new possibilities and experiences. Nothing prevents you from creating a version of Robbo, which you can finish with the help of the “passage” from the book. The book agrees well with my view of the game as an art. An art in which a player can be both perceiving and creative - if during the “game” there is an “audience” watching the player creating his own “game” story. The content of the book can be adapted for performance with a player passing Robbo, using elements of the “step-by-step instructions” from the book. Not to be unsubstantiated: a performance based on “Robbo. Solucja ”was held on May 11, 2018 in the Bunker Modern Art Gallery in Krakow, during the presentation of the book at the exhibition“ Inexhaustibility ”.
Performance in Krakow. For this, it was worth writing a compiler.

Also popular now: