Making a Modula-2 compiler for many micro controllers

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. For more historical details please consult the file called 'History'.

This page is dedicated to Plov and how it grew in time.

A mailinglist was opened so that everyone can join in the development. Here is the URL: http://tech.groups.yahoo.com/group/Plov/

Plov versions.

    Plov is the PL/0 compiler as modified by Verhoeven
    
    Ver	  Comment						:     Date
    ----- -----------------------------------------------------   ------------
    0.01  First version: read symbols and store them in a list	  01 Oct 2007
    
    0.02  Introduce a limited symbol processor; aborted		  02 Oct 2007
    
    0.03  Introduce a recursive descent parser			  06 Oct 2007
    
    0.04  Fine tune the parser					  18 Oct 2007
    
    0.05  Adapt it for file IO and command line			  26 Nov 2007
    
    0.06  Try some code generation				  31 Aug 2008
    
    0.07  Streamline the IF/ELSIF construct			   1 Sep 2008
    
    0.08  Assignments need some more attention			   2 Sep 2008
    
    0.09  IF fixed, assignment fixed, LOCAL variables added	   4 Sep 2008
    
    0.10  Cleanup and make WHILE DO work			   5 Sep 2008
    
    0.11  Add 'findType' 					  11 Sep 2008
    
    0.12  Change over to PALO-2 output codes			  12 Sep 2008
    
    0.13  Improve the syntax checker				  14 Sep 2008
    
    0.14  Enable function parameters				  16 Sep 2008
    
    0.15  Fix function parameter issue (in getLocals)
	  Jump optimisation in the IF statement			  17 Sep 2008
    
    0.16  Improve errorhandling, add operators                    20 Sep 2008

    0.17  Changed 'Condition' back to previous version
          Implement 'IRQ', 'INC, 'DEC', 'PORT'			  21 Sep 2008
    0.18  Improve IO support					  28 Sep 2008
    
    0.20  Add PROCESSOR;
	  Change symbol table fields;
	  Abandon ALTO concept in favor of direct code generation;
	  Add TYPEs Bit, Byte;
	  From now on, a Variable is ALWAYS a signed 16 bit INTEGER;
	  Registers are unsigned 8 bit entities;
	  Bits are 1 bit entities;				   9 Feb 2009

    0.21  PALO/ALTO is back, direct code generation is too complex;
          More type checking; better type names;
	  Added binary data format : b001,1101,1010 (',' is optional);
	  isBIT and isIOPORT have been removed (redundant now);
	  RamStart and SRAM now Constants included in symboltable;
	  PALO code must be FREE of ANY symbols;
	  Started implementing new parsing rules;                 15 Feb 2009
	  
    0.22  Fixed the missing parenthesis in 'FETCH LOCAL';
          Optimized local variables and parameters;
	  NumberHandler added as a PROCEDURE;
	  Changed 'Vectors' section and added CodeStart;
	  Changed symbol table with fields 'locals' and 'params';
	  Changed 'STORE' into 'NUMBER';
	  Changed position of 'RELEASE', added 'CLAIM' and 'RETURN';
	  Added hexadecimal numbers;
	  New system variables: RAMtop, HEAPstart;		  10 May 2010
   

It's time for a change: YES, we CAN!

The target for Plov020 was to hone the performance of the compiler by adding some compiler specific keywords to Palo. And to see if some real code could be generated. This IS a code producer, this project.
But at that time, I got entangled in some of my other interests again. And I got some people in my neighborhood who decided it was time to become dead. That takes up a lot of time and energy. So I had some time to overthink the situation, Somewhere, in the back of me head, there was this feeling that Alto is not such a good idea, if implemented as a low level compiler.

There had to be a simpler way. Make it as simple as possible. But not simpler. Alto as a backend compiler was simpler. It was overly simple, thereby introducing complexity again.

It took some time until the penny dropped. Alto as a backend generator is unwanted. Alto need not be implemented on the development platform. Alto need to be implemented on the target system and Palo must produce a bytecode similar to Java or Forth. So the sequence is:

  1. Plov checks the syntax of the source program
  2. On the fly, Plov generates human readable Palo code
  3. The Alto backend converts Palo code into Alto code, based on the Palo source plus the nitty gritty of the target processor system (using some kind of project file)
  4. The Alto (byte) code is uploaded to the target
  5. The target interprets the (semi compiled) Alto code using internal routines
So now the object is to define the Palo code as clearly as possible and implement it on the target processor. It will "run" the Alto code at near full speed. In fact it will run as fast as an in assembly language hand coded program that is littered with MACRO instructions.

About Alto

Alto needs to do the following things:

So it's back to the drawing board.

This page created 17 September 2008

Page equipped with googleBuster technology