Re: disruptors of & inventory of Ada compilers and latest their era of ISO8652 compliance

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

On Wednesday, May 9, 2018 at 12:34:43 PM UTC-5, Lucretia wrote:
> On Wednesday, 9 May 2018 18:26:45 UTC+1, Dan'l Miller  wrote:
> > On Wednesday, May 9, 2018 at 11:41:24 AM UTC-5, Lucretia wrote:
> > > On Wednesday, 9 May 2018 16:30:17 UTC+1, Dan'l Miller  wrote:
> > > 
> > > > 3) FSF GNAT for LLVM
> > > 
> > > Doesn't exist.
> > 
> > Well, I am counting this effort on attempting to resurrect DragonEgg in later versions of GCC:
> > https://github.com/xiangzhai/dragonegg
> 
> I wouldn't. Given the glacial movement, that'll never happen.

What is weird about DragonEgg is that it isn't merely a new backend ISA implemented the same way any new hardware-processor-machine-code ISA is implemented, e.g., RISC-V.  DragonEgg's source code has all sorts of rather surprising awareness of various hardware-processor machine-code ISAs and OSes:  ARM, MIPS, x86, MacOS/Darwin, the BSDs, and Linux.  I wonder why the design of an LLVM IR backend for GCC wasn't merely just another machine-code downstream from GIMPLE, e.g., as (hardware-processor machine-code ISAs are) overviewed at https://kristerw.blogspot.com/2017/08/writing-gcc-backend_4.html

The more that I examine DragonEgg's source code, the more I realize that DragonEgg seems like an over-complicated design that is quite fragile, which is probably why it fell into disfavor over at LLVM.

On this note, does anyone know how much GNAT's frontend
1) authors GENERIC solely,
2) a combination of GENERIC and GIMPLE,
or
3) (as reported for the modern C frontend in GCC) skips GENERIC entirely to author solely GIMPLE?
I haven't dug that deeply, that comprehensively yet into GNAT's backend-facing layer in GNAT's frontend.