Synchk project

Making a Modula-2 compiler for many micro controllers,
with the Mocka Modula-2 compiler.

This page describes the attempts to make a small Modula-2 compiler for micro controllers. I called this compiler the 'm4m compiler'. Later I changed the name some times and now (Oct 2007) the name is Plov.

The SynChk project.

This topic has been on my wishlist for quite some time. The first real attempt was a compiler like I would have made it from scratch: a multipass compiler. My line of thought used to be: on modern fast machines, it doesn't care if it's a 10-pass compiler. You won't mention the loss of performance anyway. So the SynChk part was born.
The aim of Operation SynChk was to make a syntax checker (hence the name) for Modula-2 input files. If there would be errors, they would be flagged and caught by the checker and the actual compiler would have less work, since it's input would always be valid code.

So I set off. The result was what can be found in the 'SynChk' section. My first goal was to make a comment interpreter. If the checker finds a comment, it looks for the (nested) end of comment token and disregards all it finds in between. This would enable me to develop the other parts of the checker: if something goes wrong beyond expectations, I would just comment out the particular parts and hence get to know where the error might be.

The Oberon project.

In the mean time I got befriended with Les May, an ornithologist from the United Kingdom, who programs his own data loggers. He convinced me that Oberon was a far better language than C++ for making graphic content. He didn't need much time for that.. :o). Read more about my Oberon pages.

One thing lead to another and before I knew it, I was stocking up literature on Oberon and it's related subjects. Since I was 'into' making a compiler, I was intrigued by the book 'Compiler construction' by my Heroe Niklaus Wirth. This book describes how to use simple techniques to build state of the art compilers. In his book, he describes the formation of a compiler for Oberon-0, a subset of Oberon.

I like the idea about a small compiler with a high degree of robustness. So now I want to make an Oberon-0 compiler for small micro's.

Pitfall number one: Texts.

Since the example compiler is written in pure Oberon, it borrows a lot of functions from typical Oberon libraries. One of these is Texts. The library Texts handles all text based I/O for Oberon, with tiled windows in the back of your head.
This is a problem and an opportunity in one. The problem: Texts is not available for Mocka or any other flavour of Modula-2. The opportunity: now we can make one.

Here is a code snippet of the Scanner module: 

  MODULE OSS; (* NW 19.9.93 / 17.11.94*)

    IMPORT Oberon, Texts;

    ....

    PROCEDURE Mark* (msg: ARRAY OF CHAR);

    VAR  p: LONGINT;

    BEGIN
       p := Texts.Pos(R) - 1;
       IF p > errpos THEN
          Texts.WriteString (W, "  pos ");         Texts.WriteInt (W, p, 1);
	  Texts.Write (W, " ");                    Texts.WriteString (W, msg);
	  Texts.WriteLn (W);                       Texts.Append (Oberon.Log, W.buf)
       END;
       errpos := p;
       error := TRUE
    END Mark;

    PROCEDURE Init* (T: Texts.Text; pos: LONGINT);

    BEGIN
       error := FALSE;
       errpos := pos;
       Texts.OpenReader (R, T, pos);
       Texts.Read(R, ch)
    END Init;
The IMPORT statement refers to two unknown libraries: Oberon and Texts. I will have to find out what they do. In the procedure 'Mark' are the first references to functions from Texts. Some look familiar to the ones we know from the InOut library so porting will not be much of a problem. Append and OpenReader might cause some problems. But most probably I can reuse part of the functions defined in FileIO from the Coco/R package.

Of course things can always be done simpler (according to my hero). And so I did it simpler. Instead of making some typical Oberon modules for Mocka, I adapted the Oberon source to Mocka. All functions from the Texts modules are replaced by their closest equivalents from textIO and InOut.
The results can be seen in the OSS section (in the navigator frame on the right).

Pitfall number two: among geniuses.

Before the internet was popular, I thought of myself as a more than averga smart guy. That changed. I still think I'm not stupid, but I came to recognize that I'm not that smart after all. Wirth seems to be one of the real geniuses, like just about every student at his university.
One example: read the man's sources. I need to put statements on a separate line, to keep track of what I'm doing. But for really smart people this doesn't seem to be a problem. They can read a less than optimal formatted source and still understand what's goin on. Which makes me rewrite most of the published sources such that they meet my criteria.

Since I'm definitely not among the geniuses in this world, I also need more time to grasp the content of the texts. I get the clue, since the Wirth books are very clearly written. But if certain steps are not detailed enough, I need to think really hard to understand what's going on here.
Which brings me to the point why I need so much time to go on with my version of the compiler.

OSP and OSG: the big push.

I started work on the OSG and OSP modules but this is quite a work. Lots of qualified imports going back and forth. I tried to dig myself through the OSP module, but got stuck several times. Remember: I'm not a genius. I need time.
Yesterday, I had a bright moment (or rather: THE bright moment of March) and decided to merge OSP and OSG into one file and call that file Oberon0.mi. This removes the majority of qualified imports and makes the transfer from an Oberon controlled task into a Linux command line executable. See how it works out...

At some point in time I figured that Oberon-0 is a too complex language for making a first compiler and too complex for a small microcontroller. Who needs records and such on an AVR running a thermostat? So I abandoned the OSG/OSP line altogether. The new target is PL/0.

The EBNF scanner from Compiler Construction.

I entered the EBNF scanner which was published in Compiler Construction (http://www.oberon.ethz.ch/WirthPubl/CBEAll.pdf) and ported it to Mocka. It wasn't extremely difficult, but it did take some more time than anticipated. You can download the tarball with sources, examples and executable from the download section. If you click the EBNF link in the navigator you will load the sourcefile in HTML format.

The next approach: PL/0

Oberon0 is too complex to make a compiler for and it is also too potent for a small micro controller. In a mail exchange with FP we ran into the PL/0 compiler, which was presented in 'Compiler Construction' books until the early 90's.

The pre-1994 books were rather simple and so good to comprehend. Also: they used Modula-2 as programming language, not Oberon. So now everything is lined up:

Follow the action in and around the 'PL/0 topics' section in the navigator.

Plov : the extended PL/0 compiler

Plov will be based on the PL/0 compiler, with extensions and omissions. In the mean time I have been reading about Tcl/Tk and I like some of the concepts of this language. The 'V' at the end of 'Plov' is beacuase of my last name. The 'o' is instead of the '0' (zero) which makes the word easier to type.

See how far this gets us....

Well, quite far! PLOV is spitting out PALO code like crazy! I'm now in Plov007 and I tackled 90 odd percent of the PLOV language. At this moment, the IF decoder is ready and I'm working on the LOCAL symbol scanner.

Page equipped with GoogleBuster technology