Gaius wrote:
> However the p2c bootstrap tool does not produce clean C11 or g++ code
> and after working on p2c for a week - I decided to write (mc) a Modula-2
> (PIM4) to C, C++, M2 translator. This is not yet complete - but it
> almost translates all definition modules, types and constants. It
> understands PIM4 and most GNU M2 extensions. It uses a 5 pass technique
> and the ebnf grammar tool (pg) and flex - much code borrowed from gm2.
> I estimate it is about 70% complete. It can also run the C preprocessor,
> if needed and will not need FORWARD declarations. Mc will also generate
> human readable code and use the exact naming scheme that gm2 uses. It
> does not support local modules at present,
You could have saved yourself some effort there.
I have spent the last 6 weeks completely rewriting M2C in clean and readable C99/C11 (compiles on gcc5 using strict settings) and it will generate its output using a template engine expanding replaceable templates (one template for each AST node).
We will use this for bootstrapping our Modula-2 R10 compiler.
I will provide a C99/C11 template set but it would be very easy to add one's own template set for structurally similar languages such as Ada, C++, Pascal, Other M2 dialects or Oberon. It supports PIM3 and PIM4 as well as some M2 R10 extensions, most notably C-style record types where the last field can be variable size (determined at runtime allocation), Oberon style extensible records, CONST parameters, a built-in unified CONV() function and an ISO M2-style SYSTEM.CAST() function.
It doesn't require FORWARD and the front end supports all of PIM3/4 including module priority and local modules, however, I will focus on bootstrapping our M2 R10 compiler, so I will leave the implementation of local modules in the back end for later, same for coroutines.
Eventually though this shall serve also as a PIM3/4 to M2 R10 translator, and thus all the PIM features will be implemented, including local modules, even though they are a serious pain with very little gain.
The front end is already complete and operational and I expect to have the back end complete by end of January. The front end builds an AST which can be written out as an S-_expression_. The AST is an ADT and it has a very streamlined API (8 or 9 functions) that allows both building an AST as well as walking it. The parser has absolutely no knowledge of the internal structure of the AST nor of any of the AST nodes.
Initially I adopted the licensing from Makarov's M2C as I expected to only replace the front end and marry it to Makarov's back end but given the state of that code base, I decided it was better to just rewrite the whole lot, so we are now going to use the LGPL instead.
The repo can be found at:
It seems you are about as far into your bootstrap compiler rewrite as I am into mine, so it is probably too late for settling on a common bootstrap platform now, but I thought I should mention it anyway. Apologies for not having mentioned it earlier.
regards
benjamin