Oberon-0

In the beginning the world was empty. Then came Niklaus Wirth and he created order. One of his orders was the Oberon0 compiler, presented in 'Compiler construction' (see the download section for details). In the book, four files are presented:

OSS : the text scanning routines
OSP : the Oberon0 parser
OSG : the code generator
RISC : an interpreter for a virtual RISC processor

I took the liberty to port the OSS module to Mocka, as you can see in the OSS section (consult the navigator frame) on the right.

After having rewritten the OSS module such that it doesn't report syntax errors any more, I wanted to do the same for the OSP and OSG (parser and code generator) modules. This, however, caused some troubles. I mention:

Lots of qualified references with respect to modules OSS and OSG from within OSP
Some record field names in OSG were a bit too cryptical
OSP and OSG were rather intertwined

The consequence: I lost track. So after having reformatted large parts of OSP and OSG, I came to my senses and decided to merge OSP and OSG in one file and call that file Oberon0. This way I have much less qualified imports and references. The source becomes easier to manage for me. Now I only need to make it compilable and then, after everything is acceptable to the compiler I need to make it work as intended originally. Not quite a trivial job.

The parser reads the text fragments reached out by OSS (the scanner) and checks how well they fit in the Oberon0 EBNF definitions. If they do fit, the code generator will produce 'code' but not in the sense of a usual code generator. The Oberon0 module will not produce machine code or even assembly language. Oberon0 will spit out Palo, an intermediate language. Palo is the language for a virtual stack machine and Palo programs are pure text files.
The meaning behind this all, is to create a front-end/back-end compiler system. The Oberon0 compiler will do the semantics and produce errorfree intermediate code for a non existing processor called 'Palo'.
After the Oberon0 compiler works, the Palo code can be used to write dedicated object code for just about any real processor, using the back-end generator called 'Alto'. In short:

Palo is produced by the front end generator
Alto will then generate object code for the target processor

This way, one source will be able to be used on many targets using the Palo Alto scheme. If you have a new processor, you will only need to write a new backend for it, called 'Alto' that accepts Palo as input. Simple as pi.

"But then", the smart guy is quibbling to himself, "why don't you use 'C' instead of the Palo language? C is the universal assembler language, don't forget that!". And in a way that person is right.
My reason to come up with the Palo language was rather simple. If Oberon0 is to produce C code, it must produce errorfree C code and C is mainly targeted to the PDP-8 processor. Not many of them around, nowadays. The Palo language on the other hand is a simple language, with a slight resemblance to Forth.
Forth used to be the universal assembler, until some C guys borrowed it, never to give it back. Palo is like Forth. Palo is easy to implement in just about any processor. You could even use your assembler of choice and just translate all Palo instructions into macro's to produce a simple Alto back end generator. Try that with C....

OK, there are lots of C compilers around. And for those cases, it could have been better to have Oberon0 produce C code. But there are still lots of processors that are not covered by a C compiler. And writing a C compiler is not as easy as writing an Oberon0 compiler.... So in the end, it will pay off to use the Palo Alto detour.

People familiar with the life and times of Professors Wirth and Gutknecht by now will understand why I chose the names for the front/back end generators. Call it a tribute to three parties.

Project abandoned. Too complex for me. Perhaps I will pick up work again after I have finished the Plov compiler.

Page created March 2006,

Page equipped with GoogleBuster technology