[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 19:23:37 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
Benjamin Kowarsch <trijezdci@gmail.com> writes:
> On Sat, 22 Jul 2023 at 15:05, Gaius Mulley <gaiusmod2@gmail.com> wrote:
>
> 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 am not sure that this would produce readable C output. If you let the GCC
> middle infrastructure do transformations on the syntax tree, there will most
> likely be significant changes relative to the original input. The
> resulting code would likely be very low level and thus difficult to read and
> debug. For example it would probably split up expressions into smaller and
> smaller sub-expressions. It may even turn WHILE and REPEAT and FOR
> loops into label and goto based equivalents.
>
> I still consider the approach of transforming the syntax tree in its
> original form from Modula-2 to C as close as possible and as often as
> possible in a 1:1 manner to be superior.
>
> regards
> benjamin
Ah yes - generating the C at that point would be less readable. Perhaps
generating C pre-gimplification would be better. (Just prior to
gimplify_function_tree in the gcc code base). Ironically I use this
technique to debug gm2 - there is a m2pp.cc pretty printer which
attempts to generate M2 from the gcc trees.
Here is an example working on this source code:
MODULE testnew5 ;
FROM Storage IMPORT ALLOCATE ;
TYPE
ptr = POINTER TO RECORD
a, b: CARDINAL ;
END ;
(*
test -
*)
PROCEDURE test (VAR p: ptr) ;
BEGIN
NEW (p) ;
WITH p^ DO
a := 1 ;
END
END test ;
VAR
n: ptr ;
BEGIN
test (n)
END testnew5.
$ gdb cc1gm2 etc
(gdb) break gimplify_function_tree
(gdb) run
(gdb) print modula2::pf(fndecl)
(*
test - static,
*)
PROCEDURE test (VAR p: (* <!g> *) POINTER TO (* <!g> *) RECORD
a : (* <!g> *)
CARDINAL;
b : (* <!g> *)
CARDINAL;
END) ;
(* variables in function_decl (decl_initial) *)
VAR
(* block variables *)
_T103 : (* <!g> *) POINTER TO (* <!g> *) RECORD
a : (* <!g> *) CARDINAL;
b : (* <!g> *) CARDINAL;
END ;
_T102 : (* <!g> *) POINTER TO (* <!g> *) RECORD
a : (* <!g> *) CARDINAL;
b : (* <!g> *) CARDINAL;
END ;
_T100 : (* <!g> *) POINTER TO ADDRESS ;
(* testnew5.mod:14 *)
(* variables in bind_expr *)
_T103 : (* <!g> *) POINTER TO (* <!g> *) RECORD
a : (* <!g> *) CARDINAL;
b : (* <!g> *) CARDINAL;
END ;
_T102 : (* <!g> *) POINTER TO (* <!g> *) RECORD
a : (* <!g> *) CARDINAL;
b : (* <!g> *) CARDINAL;
END ;
_T100 : (* <!g> *) POINTER TO ADDRESS ;
(* bind_expr_block *)
;
(* statement list *)
(* testnew5.mod:16 *)
(* variable in decl_expr *)
_T100 : (* <!g> *) POINTER TO ADDRESS ;
(* testnew5.mod:17 *)
(* variable in decl_expr *)
_T102 : (* <!g> *) POINTER TO (* <!g> *) RECORD
a : (* <!g> *) CARDINAL;
b : (* <!g> *) CARDINAL;
END ;
(* testnew5.mod:17 *)
(* variable in decl_expr *)
_T103 : (* <!g> *) POINTER TO (* <!g> *) RECORD
a : (* <!g> *) CARDINAL;
b : (* <!g> *) CARDINAL;
END ;
(* testnew5.mod:16 *)
BEGIN
_T100 := CAST ((* <!g> *) POINTER TO ADDRESS, p) ;
(* testnew5.mod:16 *)
m2pim_Storage_ALLOCATE( _T100, 8) ;
(* testnew5.mod:17 *)
_T102 := ( CAST ((* <!g> *) POINTER TO (* <!g> *) POINTER TO (* <!g> *)
RECORD
a
: (* <!g> *) CARDINAL;
b
: (* <!g> *) CARDINAL;
END,
p))^ ;
(* testnew5.mod:17 *)
_T103 := _T102 ;
(* testnew5.mod:18 *)
(_T103)^.a := 1 ;
END test ;
ok so still pretty verbose and unpleasant :-). But with a little work I
suspect it could look much neater (declaring a global type and reducing
clutter/tempories etc). I guess the major attraction is portability
rather than language conversion,
regards,
Gaius