Re: Runtime startup code for the GNAT Runtime...and a bit of humble pie.

[Brian Drummond <brian@shapes.demon.co.uk>]

On Tue, 26 Mar 2013 17:28:51 -0700, Diogenes wrote:

> On Tuesday, March 26, 2013 5:57:21 PM UTC-4, Shark8 wrote:

> The GNAT Runtime is SUPPOSED to be Neutral. It tries to separate the
> runtime into GNARL(The Independent part of the runtime) and GNULL(The
> platform specific part of the runtime.)
> The problem is navigating the code. You have to check both the spec and
> the body. And there you have a real spaghetti factory going on. For
> example...
> 
> Ada.Exceptions withs System.Standard_Library System.Standard_Library
> withs System.Memory System.Memory(body) withs Ada.Exceptions
> 
> Ummm...yeah...how to unravel that one?

This is not actually circular : more of a helix since the loop is closed 
by a (body) dependent on the start point. So, while I take your point, 
it's not actually unclean like #include, but definitely harder to read 
and understand.

> So I figure I might just be better off writing my own implementations of
> these things that have NO circular dependencies. One specific goal of my
> runtime is a clear hierarchy that progress directly from ada.ads out to
> the leaf packages(nodes). No circular deps. No package should depend on
> another package that depends on the first package.
> 
> This structure should take about %60 of the teeth gnashing out of the
> porting process.

Excellent. I wonder if it is possible to work towards a completely non-
Gnarl runtime with a compatible API so that there are no changes required 
to the compiler? 

One (possible) advantage of that would be that we could start with a 
clean sheet on the license conditions if we wanted : the FSF Gnat tree 
seems to have inherited the GMGPL exception while Adacore's Libre tree 
and a lot of derivatives including ORK are pure GPL. 

To me, an unambiguously GMGPL RTS would seem an advantage (though I can 
understand if you regard pure GPL as the only way to go)

For my part I am considering undertaking only as much as is required to 
support Ravenscar and making that as small as possible, but a lot of 
shared understanding will help both projects.

- Brian