gm2
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GM2 on Darwin 20.4.0/M1


From: Gaius Mulley
Subject: Re: GM2 on Darwin 20.4.0/M1
Date: Sat, 22 Jul 2023 07:05:32 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Benjamin Kowarsch <trijezdci@gmail.com> writes:

> s/# 0/<= 100/
>
> On Thu, 8 Jun 2023 at 15:21, Benjamin Kowarsch <trijezdci@gmail.com> wrote:
>
>  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.

Hello,

it would be possible to write a gcc tree to C99 "backend" - probably post
gimplification and replacing the call to lowering the trees with the new
C99 "backend".  I guess line number debugging could be preserved.  There
would be a charm adopting such an approach re: portability and for multiple
languages if done well - it would also be interesting to see the performance
cost - intriguing

regards,
Gaius



reply via email to

[Prev in Thread] Current Thread [Next in Thread]