[Oberon] Conditional compilation using IF const THEN

[Chris Burrows]

> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> Andreas Pirklbauer
> Sent: Sunday, 12 August 2018 5:18 AM
> To: ETH Oberon and related systems
> Subject: [Oberon] Conditional compilation using IF const THEN
> 
>    > Yes - I have the historical interest. I've been trying to get
> hold of a copy of
>    > the source of Wirth's single-pass Lilith Modula-2 compiler for
> the last 10 years!
>    > I don't suppose you'd know any squirrels who might have get a
> copy?
> 
> Ok, so you re referring to the Modula-2 compiler that was
> (re)designed in the summer of 1984 to become the very first *single-
> pass* Modula-2 compiler.

That's correct. The release notes of the Single-pass compiler and the sources of the original 4-pass ETH Lilith compiler and the MacMeth 68K single-pass compiler are on my Modula-2 webpage:

http://www.cfbsoftware.com/Modula2

> 
> So if you have any of them (e.g. MacMETH which is available), the
> source code will be *practically identical* to the Lilith one -
> except for the backend of course, which however you can get e.g. from
> the 1982 four-pass compiler (which is also available). So with a bit
> of work  ;-)
> 

That was what I started to do a couple of weeks ago. The executable of the single-pass M2 Lilith compiler (M2SP say) exists on the EmuLith disk images and as a proof of concept it worked. The single-pass M2 compiler is very compatible with the MacMeth sources. After removing all of the 68K-specific code I only needed to make a few source code changes to successfully compile about a dozen source code files. That's about 1% of the 'bit of work' completed. The rest will have to wait for a rainy day ;-)

It is nearly 25 years since I last did any serious work with Modula-2. After only working on the M2SP system for a few days I got more insight into what motivated the evolution of Modula-2 to Oberon just a couple of years later. In particular:

* The disappearance of the CARDINAL data type. 

* M2's cumbersome way of handling IMPORT / EXPORT, definition files and implementation files. Oberon's IMPORT / EXPORT mechanism is so much easier to work with. 
 
You may well be wondering why I would bother, and what relevance does it have to Oberon? I believe there is always a lot to learn by revisiting history. Some really good ideas can just get forgotten, or for whatever reason were not feasible at that time e.g. Da Vinci's helicopter.

Conditional compilation using 'IF const THEN' was just one of the ideas that came out of this exercise. Another was Lilith's post-mortem debug facility which would be a useful addition to Project Oberon. As well as the normal trap information you get with Project Oberon, it shows the Module / Procedure callback trace and the names of variables and their values at the time of failure. The compiler would need to be modified to produce a 'reference file' which identifies the addresses corresponding to module / procedure / variable names which the Project Oberon trap mechanism could then use when displaying the contents of memory in a recognisable form,

Regards,
Chris

Chris Burrows
CFB Software
http://www.astrobe.com/RISC5