On Thu, 8 Jun 2023 at 06:19, Gaius Mulley wrote:
> Gaius, perhaps you want to consider a back end that generates C99 from Modula-2 input for such situations.
6 failures out of 11000 is pretty good. The failure of 6 is likely one
test failing 6 times (involving select iirc and coroutines). I suspect
it is easier to fix the regression test failure than write a back end
for C99 :-)
It isn't only about this particular case. Whatever the situation may be, with a C99 backend, you are (almost*) always covered.
How much effort this is depends mostly on the AST. I don't know what the GCC AST looks like. The AST I designed for
my PIM3/4 front-end and modified for the M2R10 bootstrap compiler is deliberately structured such that I can output C
from it nearly 1:1.
Modula-2 input:
WHILE index # 0 DO
r := r + table[index];
index := index + 1
END;
AST S-_expression_:
(WHILE (EXPR (NEQ (ID "index") (INTVAL 0)))
(STMTSEQ
(ASSIGN (ID "r") (EXPR (SUM (ID "r") (DESIG (IDXVAL (ID "table") (ID "index"))))))
(ASSIGN (ID "r") (EXPR (SUM (ID "index") (INTVAL 1))))))
C99 output:
while (index != 0) {
r = r + table[index];
index = index + 1;
}
Sure this is a straightforward example, but the vast majority of use cases actually map 1:1 or near 1:1 like that. It
can be generated directly from the AST using a template for each AST node type.
(WHILE exprNode stmtSeqNode) => while %expr% { %stmtSeq% }
The templates need to be expanded recursively then.
The biggest challenge has been to translate the identifiers in a readable/C-native-looking manner,
which I have meanwhile solved and I posted about it on this list a while ago offering the sources;
and to get the indentation right, for which I have an outfile library on top of the IO API which provides indent() and
outdent() calls in its API, while also automatically wrapping, indenting and outdenting internally when a certain line
length is being exceeded.
Preserving comments in the output will also need to be done still, both design-wise and implementation wise.
But that's not even a strict necessity. You could just live without that in GM2.
I am going to backport this to my PIM3/4 front-end and add MOCKA extensions to it so this can become a
MOCKA replacement, now that MOCKA is forever stuck in 32-bit land, but I won't add support for ISO Modula-2.
In other words PIM3/4-->C99 should eventually be covered, but there is no portable open source compiler for
ISO Modula-2 that generates C output. That's a gap that GM2 could cover.
regards
benjamin
[*] Granted, if you want to target legacy platforms like say PDP-11/RSX-11 or VAX/VMS, there won't be any C99 compliant
C compiler. The further back in time, the older the C spec of the resident C compiler will be, but even on a VAX running
VMS 5.5 (which was probably the last version to support VAX) you get DEC-C which supports C90, which is close
enough as you don't use the full feature set of C99 anyway; the most limiting factor would be the 31 character limit
for identifiers as you will need to prepend the module identifier to the exported identifiers which can easily make them
longer than 31 characters. But these platforms aren't really that important nowadays. For modern platforms C99 will do.