Re: DragonEgg has been revived

["Dan'l Miller" <optikos@verizon.net>]

On Tuesday, May 22, 2018 at 7:41:52 AM UTC-5, Luke A. Guest wrote:
> Simon Clubley wrote:
> > I'm not really bothered how that happens but LLVM seems like an
> > interesting option.
> > 
> > The real question however is will this Ada compiler still work with
> > the versions of the toolchains available 2-5 years from now or will
> > it fall into disuse just like DragonEgg did ?
> 
> It would depend on how well it’s maintained and how many people step up to
> help out.

How well maintained it is depends almost entirely on how clean the design is to be easily maintainable in the first place.  DragonEgg failed miserably at that goal (if DragonEgg even had that as a goal at all).  As I have said on other c.l.a threads in the past few days, DragonEgg's ‘guiding principle’ that the original author effectively seemed to have on his mind was evidently ‘metastasizing cancer’ as opposed to ‘quarantining’.

Instead of what DragonEgg pursued, this is what GELI (pronounced ‘jelly’), the wise person's rebuttal to DragonEgg should pursue to usher in a new era for Ada:

A) GELI must be focused on GNAT-only.
▶︎ Abandon DragonEgg's goal of LLVM back-end for non-Ada languages in GCC.
▶︎ All the GCC languages other than Ada already have an LLVM-backended compiler.  Let them go forth & prosper on their own.

B) GELI must have an extraordinarily-clean dotted line for the Liskov-substitution-principle (LSP) laser to cut an ultra-precise low-drama boundary between FSF GCC and the GELI project.
▶︎ Abandon DragonEgg's touch-too-much.
▶︎ GELI would pursue no-drama coexistence, a single low-drama rarely-modified interface-with-GNAT, and quarantining as a victorious strategy for easy maintenance long-term, perhaps indefinitely, as GELI is unlikely to be embraced lovingly by either the GCC or the LLVM communities.

B.a) The Ada iterator/cursor in GNAT that walks GNAT's full-semantically-adorned Ada IR tree to feed snippets to GIGI appears to be the least-churn lowest-drama interface in the vicinity of any member of  the set {GIGI, GENERIC, C IR tree, high GIMPLE, low GIMPLE, RTL, the rest of GNAT's GCC back-end}.
▶︎ The history of GNAT almost screams “Cut here along the dotted line” regarding that iterator/cursor.

B.b) Hence, the name GELI as initialism for:  GIGI-alternative Emits LLVM IR.
▶︎ i.e., emits LLVM IR in DRAM to a copy of the entirety of LLVM's source code imported wholesale into GCC repository as a single GNAT executable to comply with the Target Code clause of GPLv3 and the Eligible Compilation Process clause of the Runtime Exception.
▶︎ Emitting any IR–either GCC or LLVM–to a file [or mmap()ed memory] from GCC would fail to comply with the Target Code and Eligible Compilation Process causes, which in turn would make any downstream machine code generated be staunchly GPLv3, i.e., no Runtime Exception, no GMGPL.
▶︎ Moral of the story:  absolutely never emit any IR to a file (or mmap()ed shared memory.

C) Unlike DragonEgg, GELI and LLVM would absolutely not be strewn throughout GCC source code.
▶︎ No touching of GCC or LLVM source code* means no maintenance whatsoever of LLVM or the vast bulk of GNAT/GCC, other than copying them in verbatim.
▶︎ Import all of GCC and all of LLVM verbatim except for merge conflicts at the extraordinarily few places where GELI touches/modifies GCC.
▶︎ GELI would merely invoke LLVM, presenting LLVM with garden-variety LLVM IR, so GELI shall not touch/modify LLVM whatsoever, other than verbatim copying of the entirety of LLVM's source code into the GCC repository and building it.

* other than the set {the Ada iterator/cursor, its factory (method), the “llvm-” prefixed targets on the GNAT command line, scripts invoking additional tests}

D) All the ISA targets that LLVM supports now and in the future would be prefixed with “llvm-” on GNAT's command line.
▶︎ This assures that no one is ever confused due to similarly-named targets in GCC-world versus LLVM-world.
▶︎ GNAT users will know precisely which back-end is generating the machine code:  GELI feeding LLVM versus GIGI feeding GCC-back-end.

E) Additional test-cases, test-drivers, or test-suites might need to be added to stress test and regression test topics that are currently not tested or not tested well in ACATS or any of GCC's existing tests.

F) To be easily maintainable, GELI would have strictly-enforced prohibitions on modifying •anything• in GCC other than:

F.a) the GELI-replacement iterator/cursor in Ada for the Ada current iterator/cursor in GNAT that walks the fully-semantically-adorned Ada IR tree, and a factory or factory method thereof to instantiate the correct GELI-feeding one versus the GIGI-feeding one, depending on whether an LLVM or GCC ISA target was selected on the GNAT command line.

F.b) GELI's source code and the entirety of LLVM's source code and any additional test suites would merely be present co-existing in the GCC repository.
▶︎ Only the Ada iterator/cursor, its factory (method), the “llvm-”-prefixed LLVM targets on GNAT's command line, and scripts that merely invoke additional test suites would be the places at which the GELI project would not be mere coexistence of additional files & directories in FSF GCC repository.

G) If GELI's development stresses GCC or LLVM in ways that reveal a bug in GCC or in LLVM, then try to find a way of replicating the bug outside of GELI in FSF GNAT, FSF GCC at large, Clang, Flang, LLVM, or any other non-GELI project on planet Earth.
▶︎ Try very diligently to never predicate a bug fix (or worse, new-feature request) at GCC or LLVM on GELI.
▶︎ This means GELI should go the extra mile (or ten miles) to use GCC or LLVM verbatim as is, enacting workarounds in already-extant GCC or in already-extant LLVM whenever practical.

Hence, GELI would be easily maintainable, focusing only on what DragonEgg does not focus on at all:
• the river of new Ada features & bug-fixes semantically adorned on the Ada IR by FSF GNAT;
• the addition & removal of LLVM ISA targets begetting changes to the “llvm-”-prefixed targets on GNAT's command-line;
• the rare changes in FSF GNAT to the interface to the Ada iterator/cursor that feeds GIGI;
• wholesale importing the entirety of new releases of LLVM at, say, major.minor releases of GCC.

> > There's a confidence problem here. I can write C and C++ code in 2018
> > for some random embedded target knowing there's a very very good chance
> > I will still be able to compile that code on the freely available
> > toolchains which will exist 5 years from now.

It would seem that GELI would increase your confidence via:

1) providing an alternate 2nd-source for machine-code generation of targets for some embedded processor (when GCC lacks a target, LLVM might support it);

2) providing an easily maintainable quarantining of the churn with as little drama as possible in widely-available open-source repository;

3) complying fully with the Target Code and Eligible Compilation Process causes of the GPLv3 and its Runtime Exception to assure that machine code generated by this GELI-feeds-LLVM back-end would be distributable as you please for execution

3.1) Importation of GCC-emitted-as-Target-Code machine code into McSema for reworking would still be encumbered by GPLv3, as that machine code would be deemed IR by the Target Code & Eligible Compilation Process clauses.

> > As I have said before, the language is _really_ good, but the compiler
> > situation is lousy.
> 
> We need a new one not controlled by a company/monopoly.