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

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

On Monday, May 14, 2018 at 8:10:53 AM UTC-5, Jacob Sparre Andersen wrote:
> Dan'l Miller wrote:
> 
> > 1) AdaCore's GNAT Pro
> >    - Ada2012 plus (some?) emerging Ada2020
> >    - very actively maintained
> 
> You could say so.
> 
> > 2) FSF GNAT in GCC
> >    - Ada2012
> >    - sporadically maintained (i.e., bleeding-edge combination of
> >      current-wavefront GCC backend with effectively retrofitted AdaCore
> >      GNAT front-end from an older release of GCC)
> 
> Nope.  Changes are continously - except when GCC has a code freeze -
> ported from the internal GNAT Pro development branch to the public GCC
> development branch.  (My understanding.  I'm neither working for FSF nor
> for AdaCore.)

TL;DR; this self-contained single paragraph is an alternate wording of the crescendo of logic in the subsequent multiple paragraphs below:
Does AdaCore fix ••in the exact same minor-dot-release of FSF GCC•• (e.g., 8.0) the bugs that were introduced by the merge from GNAT-Pro development branch to current wavefront of FSF development on the public GCC branch?  Let alone minor; in recent years, does the fix always arrive in the same major (e.g., 8.X for any X) release of FSF GCC as when the merge introduced the bug into FSF GNAT's current wavefront of new development?  Do the bugs introduced by the merge from GNAT-Pro development branch into, say, GCC 8.0 sit there unfixed until (after a round-trip of adopting GCC 8.X into the GNAT-Pro development branch, itself merged with bug fixes back to FSF weeks or months or a year later), AdaCore releases fixes for, say, a hypothetical GCC 8.3 release, which again leaves, say, GCC 9.0 buggy for a while (e.g., until AdaCore maintains the 9.X release by the time of, say, a hypothetical 9.3?  If such a multi-minor-release-spanning (or worse, multi-major-release-spanning) window of FSF GNAT bugginess exists due to release-number difference between GNAT Pro and FSF, wouldn't that be •sporadic• (as some minor releases of FSF GNAT get a yep-FSF-GNAT-is-reliable checkmark and others don't for months-long or year-long durations)?

The longer version of crescendo:
  I am not merely focusing solely on mechanical merges of source code that merely minimally compile.  (What •precisely• is the criterion or criteria for success that AdaCore utilizes to “port[] from GNAT Pro development branch to the public GCC development branch” that discerns A) a rejected change to the public GCC development branch that needs more grinding before being released publicly from B) an accepted change to the public GCC development branch that is good to go?  Is it merely successful compile & link?  Is it passing all of ACATS or some other rigorous regression test suite?)

I utilize the term “maintenance” of software, whereas you utilize the term “porting”.  What is the difference?
https://en.wikipedia.org/wiki/Software_maintenance

Porting focuses on the mechanical-esque adaptation of some origin source code into some different destination larger body of source code or some different larger system.  Not only does software maintenance subsume porting, a key part of maintenance of software includes (from that Wikipedia article and decades of wisdom from Lehman et al) “4. The process acceptance of the modification, by confirming the modified work with the individual [e.g., FSF and the public] who submitted the request in order to make sure the modification provided a solution.”  That criterion #4 is what I am focusing on in the “sporadically” term.

After ••every single merge•• of a unit of work (e.g., bug fix; new feature) from AdaCore's GNAT Pro development branch to the public GCC development branch, does AdaCore run a hard-hitting battery of regression tests •••on the resulting FSF branch••• to assure that no bugs were introduced (e.g., due to mismatch with the different release of GCC)?  Or is that finding of fresh bugs (i.e., the ones that were introduced sympathetically by the merger itself that were not present in FSF GNAT prior to the merge from GNAT Pro) the job of the so-called ‘community’ outside of AdaCore?  In so far as this non-AdaCore FSF GNAT community is voluntary, wouldn't that be •sporadic• since voluntary labor is a finite resource smaller than the demand (of mismatches due to different Pro-to-FSF-mismatched GCC versions)?  Yes, I have no doubt that the merge and minimal does-it-compile-&-link check is performed very frequently.

But is the regression test suite performed equally as frequently on •FSF GNAT• during/immediately-after a merge from GNAT Pro?  Precisely where can I see daily or weekly exhaustive regression-test pass/fail results (especially showing near-100% success rate) regarding the GNAT-Pro-to-FSF merges?  When a fresh bug is introduced to FSF GNAT due to a merge from GNAT Pro, who ‘gets right on that right away’ to fix that bug just introduced in FSF GNAT by the public merge from GNAT Pro:
1) AdaCore (directly) who just performed the Pro-to-FSF merge hours or days ago
or
2) the so-called ‘community’ (i.e., non-AdaCore)
or
3) AdaCore (indirectly) as they eventually adopt that later GCC release into the GNAT Pro development branch weeks or months or a year later?  Wouldn't the weeks or months or year of this option #3 be •not• publicly ‘getting right on that freshly-introduced bug right away’?  Wouldn't the lack of bug fix right away along that public FSF GCC branch in the same GCC minor release number be •sporadic• maintenance of such a buggy merge, if one ever exists?

If community #2 there, then wouldn't that be •sporadic• as volunteers eventually find time to volunteer their time?  If AdaCore #3 there via eventual adoption of that different later version of GCC into the GNAT Pro development over a period of weeks or months or even a year, then wouldn't that be •sporadic• by the time that that cycle of development makes a not-immediate round-trip back to FSF GNAT?

Does AdaCore continuously adopt into the GNAT Pro development each incremental continuous-integration evolution to the GCC wavefront of new development or does AdaCore adopt a different later release of GCC as a convulsion in one big gulp?  If one big gulp, then wouldn't that be •sporadic• as fixes for bugs introduced into FSF GNAT via merge from the (older-GCC-release) GNAT Pro development branch into the (later-GCC-release) current-wavefront of new GCC development branch often(?) wait for the adoption of a later-release GCC on the GNAT Pro development branch weeks or months or even a year later?

Aren't we just exploring here how the dictionary definition of the word sporadic plays out meticulously ramification-by-ramification within what we perceive externally are the GNAT-Pro-to-FSF release process is and later-GCC-release-to-GNAT-Pro adoption process?  What better word than sporadic exists in the dictionary for this back-&-forth round-trip-of-later-GCC-release-to-GNAT-Pro-then-AdaCore-development-then-eventual-merge-to-a-still(!)-later-release-of-GCC  state of affairs?  Pendulum (with a periodicity of months or year)?

> > 5) Tartan Ada (DDC-I)
> >    - Ada1983 (Ada1995 work by Tartan didn't survive acquisitions?)
> >    - legacy only(?) for DSPs & TI processors
> 
> I don't know about Tartan Ada, but DDC-I sells Ada 95 compilers for a
> number of targets: https://www.ddci.com/products_score/

From Texas Instruments, on various (but not all) processors, DDC-I purchased the rights to the  Tartan Ada compiler written by the company that (the) Dr. William Wulf's and wife founded, based on their pioneering work on the BLISS optimizing compiler, one of the first compilers with an optimizer phase.  You know, the William Wulf who is one who in 1971 added fuel to the MIMD and hypervisor fire via c.mmp and Hydra which were precursors, respectively, of a) modern MIMD in SPARC UMA crossbar and the crucial need for the cache-coherent part of ccNUMA processor confederations (e.g., AMD HyperTransport & Intel QPI instead of the crossbar) and b) all the modern hypervisors (e.g., VMware, Hyper-V).  You know, the one who first popularized/advanced/industrialized the idea for an •optimizing• stage within compiler backends.  That William Wulf.  Btw, Tartan was where Guy Steele worked as a young man prior to co-designing Java almost 2 decades later.

> > 6) PTC's ApexAda (formerly IBM Rational Ada)
> >    - Ada2005
> >    - actively maintained
> > 7) PTC's ObjectAda (formerly Aonix's ObjectAda)
> >    - Ada1995(?)
> >    - actively maintained
> 
> PTC has three Ada compilers they are selling.  Two of them are
> supposedly in active development, but I can't remember which.
> 
> > 8) HPE's Ada (formerly DEC's Ada)
> >    - Ada1995(?)
> >    - legacy only on OpenVMS
> 
> Not something I've heard of.
> 
> > Are there any others still extant?
> 
> Green Hills Software still sells the Green Hills Ada (95) compiler.
> 
> XGC Technology sells four variants of their Ada 95 compiler.
> 
> > Is it true that absolutely no Ada compiler vendor other than the 3
> > variants of GNAT (counting the LLVM one as a limping-along 3rd
> > variant) have achieved the bulk of the Ada2012 feature-set in
> > approximately six years?
> 
> You would have to check with PTC and RR Software, to hear if they have
> implemented "the bulk" of Ada 2012 yet.  PTC are implementing Ada 2012
> features prioritised according to the needs of their customers (whatever
> that means).
> 
> > What disruptors are foreseeable to change any of this significantly?
> > - fresh new Ada compiler (e.g., Byron)
> > - drastically-divergent fork of GNAT
> > - faster Ada-compiler development at RR Software or PTC so that they
> >   support Ada2012 and Ada2020 by, say, 2023?
> > - resurrection of effectively dormant source code bases at HPE or
> >   Tartan/DDC-I?
> 
> The third option seems most likely.  RR Software has already implemented
> some Ada 2012 support, and they clearly intend to expand it.
> 
> I think it is unlikely that somebody can get sufficient funding to
> create a new Ada compiler from scratch.
> 
> I can't see the point in forking GNAT, and DDC-I & co. seem quite happy
> milking their existing customers, so don't expect anything from them.
> And given what you pay for a PTC Object Ada license, I can't see how
> they can get enough customers to fund any serious development.  And it
> doesn't seem like their management is interested in making an investment
> (unlike RR Software).
> 
> Greetings,
> 
> Jacob
> -- 
> xsnow | xshovel > /dev/null