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

[Dan'l Miller]

Ada2005 = Ada2007 in ISO8652-speak
Ada1983 = Ada1987 in ISO8652-speak

Is the following inventory accurate, ignoring SPARK?
1) AdaCore's GNAT Pro
▪︎ Ada2012 plus (some?) emerging Ada2020
▪︎ very actively maintained
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)
3) FSF GNAT for LLVM
▪︎ Ada2012
▪︎ unstable & experimental by one developer in 2017
4) RR Software's Janus Ada
▪︎ Ada1995 plus partial Ada2005
▪︎ actively maintained
5) Tartan Ada (DDC-I)
▪︎ Ada1983 (Ada1995 work by Tartan didn't survive acquisitions?)
▪︎ legacy only(?) for DSPs & TI processors
6) PTC's ApexAda (formerly IBM Rational Ada)
▪︎ Ada2005
▪︎ actively maintained
7) PTC's ObjectAda (formerly Aonix's ObjectAda)
▪︎ Ada1995(?)
▪︎ actively maintained
8) HPE's Ada (formerly DEC's Ada)
▪︎ Ada1995(?)
▪︎ legacy only on OpenVMS

Are there any others still extant? Who still resells which one of these (e.g., GreenHills)?

Who formerly resold which of these (e.g., back in the day, Sun ironically resold DEC's, correct?)?

Whose historical (perhaps ancient) Ada compiler is not on the list (ignoring NYU's AdaEd interpreter that served as some sort of basis for GNAT and ignoring packaging variants such as EZload of GNAT)?

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?

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?

[Lucretia]

On Wednesday, 9 May 2018 16:30:17 UTC+1, Dan'l Miller wrote:

> 3) FSF GNAT for LLVM

Doesn't exist.

[Dan'l Miller]

Well, I am counting this effort on attempting to resurrect DragonEgg in later versions of GCC:
https://github.com/xiangzhai/dragonegg

[Lucretia]

I wouldn't. Given the glacial movement, that'll never happen.

[Simon Clubley]

On 2018-05-09, Dan'l Miller <opt...@verizon.net> wrote:
> 8) HPE's Ada (formerly DEC's Ada)

> ?? Ada1995(?)
> ?? legacy only on OpenVMS
>

I'll let others answer your other questions, but I can answer this one.

This compiler is Ada 83 only.

When DEC needed an Ada 95 compiler, they contracted with AdaCore
to supply GNAT instead.

A very long time ago, back in the GNAT 3.1{x}p days before GNAT
was integrated into the GCC distribution, you could download an
official AdaCore public GNAT for VMS Alpha from the NYU FTP site
but that hasn't been true for a very long time.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Dan'l Miller]

On Wednesday, May 9, 2018 at 10:30:17 AM UTC-5, Dan'l Miller wrote:
> Whose historical (perhaps ancient) Ada compiler is not on the list (ignoring NYU's AdaEd interpreter that served as some sort of basis for GNAT and ignoring packaging variants such as EZload of GNAT)?

I forgot this dormant Ada compiler from a bygone era:

https://en.wikipedia.org/wiki/IMAX_432
9) Intel's Ada compiler for Intel's so-called Ada-processor: the iAPX 432. The operating system for the iAPX432 was iMAX432, written in Intel's subset of Ada extended with hardware-assisted garbage collection, “runtime type-checking” and “dynamic package creation”.

[Dan'l Miller]

Well, we collectively should probably feel guilty that that no one seems to have volunteered to help with the regression testing. Xiang Leslie ZHAI tagged that issue with help-wanted:
https://github.com/xiangzhai/dragonegg/issues/34

[Niklas Holsti]

On 18-05-09 18:30 , Dan'l Miller wrote:
> Ada2005 = Ada2007 in ISO8652-speak
> Ada1983 = Ada1987 in ISO8652-speak
>

> Are there any others still extant?

A couple come to mind:

DDC-I, https://www.ddci.com/

Irvine Compiler, http://www.irvine.com/

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .

[Randy Brukardt]

"Dan'l Miller" <opt...@verizon.net> wrote in message
news:d690863e-e230-4188...@googlegroups.com...
...

>4) RR Software's Janus Ada

>?? Ada1995 plus partial Ada2005

As of the preview last year, "partial Ada2012" (*very* partial) is also
included. I'm hoping to get a release version of that out next month -
possibly with more features if time permits.

Randy.

[Micronian Coder]

Green Hills AdaMULTI still only supports Ada95 with no sign of it ever going past that. Most recent announcements only focus on updates to their C/C++ products, which gives the impression that they barely maintain AdaMULTI. Of course I would love to be wrong about that, but I wouldn't hold my breath.

[Micronian Coder]

On Wednesday, May 9, 2018 at 2:38:45 PM UTC-7, Randy Brukardt wrote:
> "Dan'l Miller" wrote in message

Great to hear that Janus/Ada is still being enhanced. I only use Linux at home, so it would be great if CLAW and/or Janus/Ada ran on Linux as well. I would even be happy if CLAW and its GUI builder ran on Linux (note: I tried the introduction version under Wine and it was unusable ). I know about Gnoga, but I would be willing to purchase a low cost alternative such as CLAW if it ran on Linux.

[Jeffrey R. Carter]

On 05/09/2018 11:38 PM, Randy Brukardt wrote:
>
> As of the preview last year, "partial Ada2012" (*very* partial) is also
> included. I'm hoping to get a release version of that out next month -
> possibly with more features if time permits.

If you intend to make Janus a full Ada-12 compiler, I would be willing to
volunteer some time to assist with the effort. This is especially true if you
intend to also have a Linux version.

Probably some others here would do the same.

I have no experience in compiler writing, but if you have well defined parts of
the compiler to be implemented/modified, I suspect I could successfully work on
them.

It would be very good for there to be more than one Ada-12 compiler.

--
Jeff Carter
"I don't know why I ever come in here. The
flies get the best of everything."
Never Give a Sucker an Even Break
102

[Paul Rubin]

"Jeffrey R. Carter" <spam.jrc...@spam.not.acm.org> writes:
> If you intend to make Janus a full Ada-12 compiler, I would be willing
> to volunteer some time to assist with the effort. This is especially
> true if you intend to also have a Linux version.

I'm not selfless enough to offer to contribute to a proprietary software
product for free (and I wouldn't expect you to want to hire me), but
I'll join Jeffrey in offering a word of encouragement. I'm not that
excited about a Linux version since ISTM that GNAT works perfectly well
under Linux. But a version for embedded targets would be very
attractive. I wonder if you could team up with one of the embedded
toolchain vendors like Rowley or MPE or Forth Inc to combine your
compiler with their hardware support stuff.

[Jacob Sparre Andersen]

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.)

> 3) FSF GNAT for LLVM

> - Ada2012
> - unstable & experimental by one developer in 2017

I wouldn't count that as a compiler.

> 4) RR Software's Janus Ada

> - Ada1995 plus partial Ada2005
> - actively maintained

There's support for some Ada 2012 in Janus/Ada. Sometimes I think Randy
spends too much time here, instead of improving Janus/Ada. ;-)

> 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/

> 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

[gautier...@hotmail.com]

> 7) PTC's ObjectAda (formerly Aonix's ObjectAda)
> ▪︎ Ada1995(?)

Ada 2005 in current version (randomly: Ada.Containers, Ada.Directories, raise-with-message, object.Method notation all work fine).

[Dmitry A. Kazakov]

Interfaces?

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[Randy Brukardt]

"Jacob Sparre Andersen" <ja...@jacob-sparre.dk> wrote in message
news:87vabqs...@jacob-sparre.dk...
> Dan'l Miller wrote:
...

>> 4) RR Software's Janus Ada
>> - Ada1995 plus partial Ada2005
>> - actively maintained
>
> There's support for some Ada 2012 in Janus/Ada. Sometimes I think Randy
> spends too much time here, instead of improving Janus/Ada. ;-)

The last week or so surely qualifies. ;-)

Randy.

[Dan'l Miller]

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.

[gautier...@hotmail.com]

> Interfaces?

Yep :-)

[Dan'l Miller]

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.

[Luke A. Guest]

Dan'l Miller <@verizon.net> wrote:
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

See previous discussions about taking gcc’s ir and the ramifications of
doing so, it makes the resultant code gplv3. It’s in the gcc faq and
licence.

> On this note, does anyone know how much GNAT's frontend

GNAT IR -> generic -> gimple, but I think they got rid of the generic step
but I’m not sure.

[Dan'l Miller]

On Thursday, May 17, 2018 at 10:56:02 AM UTC-5, Luke A. Guest wrote:
> Dan'l Miller <@verizon.net> wrote:
> 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
>
> See previous discussions about taking gcc’s ir and the ramifications of
> doing so, it makes the resultant code gplv3. It’s in the gcc faq and
> licence.

1) DragonEgg is licensed as GPLv2 (as GPLv2 was the version at the time of its inception), so there is clearly no goal there in DragonEgg of making a nonGPL LLVM backend for GCC.
2) As implied by all hardware-processor machine-code ISAs in GCC, an LLVM IR as just analogous to a machine-code-ISA backend on GCC would of course be GPLv3 nowadays, just as any hardware-processor machine-code ISA would be in GCC.

> > On this note, does anyone know how much GNAT's frontend
>
> GNAT IR -> generic -> gimple, but I think they got rid of the generic step
> but I’m not sure.

Wait, GNAT has its own full-fledged IR stage prior to deriving either GENERIC or GIMPLE from that GNAT IR? By IR here, I of course mean capturing •all• the semantic behavior of the program as per the _ARM_, not merely an AST of the recognized syntax. Perhaps you are speaking of a blend: that GNAT might encode 100% of the semantics adorned on the AST itself prior to deriving either GENERIC or GIMPLE •mechanically• without adding any more _ARM_-defined Adaness. If such a GNAT IR exists that would capture all Ada-ness prior to •mechanically• deriving either GENERIC or GIMPLE (i.e., mechanically = with no knowledge of the _ARM_), then that might be the better place to shunt off to LLVM bitcode IR*, skipping both GENERIC and GIMPLE.

* a GPLv3ed LLVM-backended GNAT compiler, of course, analogous to the old llvm-gcc and llvm-g++ in the early days of LLVM

Conversely, if GNAT is still imbuing fresh _ARM_-defined Adaness into either GENERIC or GIMPLE that wasn't fully represented upstream prior to GENERIC/GIMPLE, then these imbuings would be skipped, nullifying any fleeting interest in a shunt off to LLVM bitcode IR prior to GENERIC/GIMPLE.

None of this arrives at a non-GPLed open-source Ada compiler though.

[Luke A. Guest]

Dan'l Miller <opt...@verizon.net> wrote:

>> See previous discussions about taking gcc’s ir and the ramifications of
>> doing so, it makes the resultant code gplv3. It’s in the gcc faq and
>> licence.
>
> 1) DragonEgg is licensed as GPLv2 (as GPLv2 was the version at the time
> of its inception), so there is clearly no goal there in DragonEgg of
> making a nonGPL LLVM backend for GCC.
> 2) As implied by all hardware-processor machine-code ISAs in GCC, an LLVM
> IR as just analogous to a machine-code-ISA backend on GCC would of course
> be GPLv3 nowadays, just as any hardware-processor machine-code ISA would be in GCC.

I don’t know what you’re trying to say here but it’s completely irrelevant
to what I said. There is within the GPLv3 which states if you extract the
ir from gcc in some way the resultant ir is gplv3. Like I said, see the
faq.

I’m on mobile so I’m not going looking for this stuff.

> Wait, GNAT has its own full-fledged IR

Of course it does, every compiler builds up an AST IR prior to lowering to
another IR. GNAT doesn’t use a symbol table, everything is in the tree.

[Niklas Holsti]

On 18-05-17 18:56 , Luke A. Guest wrote:
> Dan'l Miller <@verizon.net> wrote:
> 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
>
> See previous discussions about taking gcc’s ir and the ramifications of
> doing so, it makes the resultant code gplv3. It’s in the gcc faq and
> licence.

Firefox cannot find the word "intermediate" or the (upper-case) acronym
"IR" in the GPL FAQ at https://www.gnu.org/licenses/gpl-faq.html. The
word "representation" occurs once, in a different context.

Ditto for the GPLv3 itself, at https://www.gnu.org/licenses/gpl.txt.

If you extract a source-to-IR "front compiler" from the full gcc, of
course that front-compiler itself remains under GPL. But I do not
believe that IR text generated by that compiler would automatically fall
under the GPL, no more than machine code generated by the full gcc
automatically falls under the GPL.

Please provide a link or quotation to support your claim.

[Dan'l Miller]

On Thursday, May 17, 2018 at 12:19:22 PM UTC-5, Luke A. Guest wrote:
> There is within the GPLv3 which states if you extract the
> ir from gcc in some way the resultant ir is gplv3. Like I said, see the
> faq.

==PART 1==
Ah, here is the FAQ to which you are referring: it is the Runtime Exception FAQ, even though for the Target Code versus IR portion this FAQ effectively discusseses both GPLv3 itself (i.e., Target Code) intertwined with the Runtime Exception (i.e., Eligible Compilation Process).

https://www.gnu.org/licenses/gcc-exception-3.1-faq.html

I never said to •extract• any IR via any kind of dump to filesystem or sharing of DRAM with another process. I said to make LLVM bitcode merely another ISA in the backend of GPLv3ed GCC, as if LLVM were a new hardware-processor IC. (Then, I pondered an alternate form where LLVM bitcode IR wouldn't be downstream [within the GPLv3ed GCC executable] from GIMPLE, but would [within the GPLv3ed GCC executable] be downstream directly from GNAT IR in their semantically-adorned AST, but all that is still within a single GPLv3ed GCC executable without extract.)

The output of the LLVM-bitcode-IR-as-another-ISA backend would not be LLVM bitcode IR itself. The LLVM-as-an-ISA backend would be the entirely •all• of LLVM subsumed into GCC (because the so-called MIT License, i.e., X11 License, is compatible with GPLv3). The entirety-of-LLVM-subsumed-into-GCC-within-the-LLVM-bitcode-IR-as-ISA backend would produce all the actual hardware-processor machine-code targets that LLVM produces, emitted as Target Code in (apparent?) full compliance with GPLv3 and its Runtime Exception because LLVM would be housed within the single GCC executable (and merely emitting garden-variety machine code for hardware processors).

The question regarding GNAT IR becomes: how much is GNAT injecting _ARM_-defined Adaness when authoring either GENERIC (if it still is present) and/or GIMPLE, where that Adaness was •absent• in GNAT semantically-adorned-AST IR?

==PART 2==
Btw, this brings up big-time another can of worms. There is a lifter named McSema that takes any x86-64 executable (or library) as input and outputs LLVM bitcode IR—reportedly rather darned good LLVM bitcode IR. McSema = machine code semantics, a DARPA-funded project. Almost certainly this would be reverse engineering that is usually prohibited under EULAs. But does lifting GCC's Target Code x86-executable output trigger the “notwithstanding that” portion of the Runtime Exception:

quoted from the Runtime Exception:
“"Target Code" refers to output from any compiler for a real or virtual target processor architecture, in executable form or suitable for input to an assembler, loader, linker and/or execution phase. •Notwithstanding that•, Target Code does not include data in any format that is used as a compiler intermediate representation, or ••••used for •producing• a compiler intermediate representation••••.”

Does that clause mean that as soon as someone inputs GCC-produced would-have-been-TargetCode into McSema that that x86-64 executable/library •ceases• (downstream) to be Target Code, reverting to an IR, even though it is garden-variety Intel/AMD x86-64 machine code? Then causing every (downstream) derivative work to be GPLv3ed (via GPLv3 itself) and Runtime Exception revoked (downstream) and thus for good measured GPLv3ed again (via the Runtime Exception revocation)?

(Btw, McSema strips all exception handling out, because currently it is too difficult, so in at least this regard the resulting LLVM bitcode IR is lossy semantically.)

[Dan'l Miller]

On Thursday, May 17, 2018 at 12:19:22 PM UTC-5, Luke A. Guest wrote:

> Dan'l Miller wrote:
> > Wait, GNAT has its own full-fledged IR
>
> Of course it does, every compiler builds up an AST IR prior to lowering to
> another IR. GNAT doesn’t use a symbol table, everything is in the tree.

GIGI is apparently the name of GNAT's tree transducer, where at least one of the GIs stands for “GENERIC instantiation” as indicated by the following commit comment. (Perhaps GIGI stands for GENERIC instantiation GIMPLE instantiation?)
https://github.com/gcc-mirror/gcc/commit/404455fef970eea7f65545ed7ed87501ef925718

According to Figure 1 in the following reference, GIGI feeds fragments of the semantically-adorned tree to either GENERIC or GIMPLE.

https://www2.adacore.com/gap-static/GNAT_Book/html/node5.htm#fig:frontal-gnat

It seems that there are 4 variants of bolting the entirety of LLVM into GNAT:
1) make the entirety of LLVM conform to be yet another ISA in GCC fed by low-GIMPLE
or
2) make the entirety of LLVM conform via Liskov substitution principle (LSP) to obey the interface of low-GIMPLE fed by high-GIMPLE; this might preserve some information that LLVM would prefer to be thrown away as a form of semantic blindness
or
3) make the entirety of LLvM conform via Liskov substitution principle (LSP) to obey the interface of high-GIMPLE fed by GIGI; this might preserve all information that LLVM would prefer to not be thrown away as a form of semantic blindness
or
4) rewrite nearly all of GIGI* as GigiEmittingLlvm (or contorting a few letters: GiggleVM for short) to transduce the fully-semantically adorned AST to LLVM IR instead of to any of GCC's IRs; this one is clearly the best if today's GIGI is as dumb as a rock regarding further adornments of _ARM_-defined Adaness semantics to the supposedly already-fully-semantically-adorned AST. If GIGI is doing absolutely more than nose-to-the-notAda-grindstone focusing entirely on GCC internals and not devising tidbits of Ada semantics afresh**, then GIGI is our thing to gut, substituting GiggleVM via LSP, to achieve a GPLv3ed GNAT-LLVM hybrid compiler.

* but only GIGI as modified, leaving the entirety of the rest of GNAT front-end and GCC back-end 100% undisturbed*** (as opposed to DragonEgg that apparently seems to have had the word metastasize on its mind throughout its design phase).

** This GIGI-is-as-dumb-as-a-rock-regarding-devising-even-more-Ada-semantics seems quite likely given the elaborateness of the grinding that precedes GIGI.

*** except for the mere presence of LLVM's entire codebase in the GCC repository and GiggleVM calling into this LLVM-subsumed codebase in a single GPLv3ed GCC executable

[Dan'l Miller]

On Thursday, May 17, 2018 at 3:23:51 PM UTC-5, Dan'l Miller wrote:
> According to Figure 1 in the following reference, GIGI feeds fragments of the semantically-adorned tree
> to either GENERIC or GIMPLE.
>
> https://www2.adacore.com/gap-static/GNAT_Book/html/node5.htm#fig:frontal-gnat

Does anyone know (or have a URL to) why GIGI was written in C instead of in Ada? Obviously, it is calling much C code in the GCC backend world, so there is that. Was it simply because GIGI predated the addition of so much of the unchecked_* feature-set in ISO standard Ada that permits interfacing with C APIs?

The reason that I ask is because I am perplexed by the opposing boundary: the AST data structure that GIGI is traversing is an Ada data structure (i.e., instantiated & adorned by all the Ada-language code throughout the rest of the GNAT frontend), correct? So wouldn't the impedance mismatch (to borrow a EE term) between AST-versus-C at the AST-versus-GIGIc boundary have been much more immense than any annoying unchecked_* layer between GIGIada-versus-GCCbackendWorld, where GIGIc is the extant one today, and where GIGIada is the hypothetical one that was never written in Ada, and where GCCbackendWorld is all C (and nowadays some C++ AIUI).

Perhaps the LLVM replacement for GIGI should be written in Ada instead of C. Perhaps that means not LSP of the AdaFE-to-GIGI interface, where AdaFE is the rest of the frontend of GNAT written in Ada. Conversely, keeping exactly today's extant AdaFE-to-GIGIc existing interface via LSPing GiggleVM instead of GIGIc as a drop-in replacement would permit an immense amount of insulating a fork of GNAT from a vast amount of evolutionary change in GNAT's AdaFE.

(I can imagine that perhaps FSF and/or AdaCore and/or LLVM.org could all refuse to merge any attempt at this GiggleVM LSPing of GIGIc and grafting on a 2nd backend within a single GPLv3ed GCC executable. Maintaining an llvm-gnat fork outside of FSF and outside of LLVM.org might be completely unavoidable if GiggleVM LSPing of GIGIc is not embraced lovingly. I can imagine that AdaFE's GIGIc interface is low-churn historically, likely modified once per blue moon when an ISO standard Ada feature begets a change in the backend of GCC that was not already needed by C++ or any of the other languages. Having a relatively-historically-stable AdaFE-to-GIGIc interface that is low churn and thus low drama might be advantageous to long-term maintenance of an llvm-gnat fork of GCC. Lowering the drama might be worth keeping the Ada-to-GiggleVM interface exactly the same via LSP as today's Ada-to-GIGIc interface, even if it is in C.)

[Lucretia]

On Friday, 18 May 2018 01:56:12 UTC+1, Dan'l Miller wrote:

> Does anyone know (or have a URL to) why GIGI was written in C instead of in Ada? Obviously, it is calling much C code in the GCC backend world, so there is

Stallman's a C guy. His original intent with GNU was to replace Unix with a more free version by rewriting everything. They started with the toolchain, which was originally in C, now it's been rewritten in C++.

[Dan'l Miller]

Ah, you bring up an interesting point: perhaps GIGI in GNAT is borrowed from a GIGI over in the C/C++ compiler. (You might also bring up an interesting point that GIGI in GNAT was written by Stallman or some other “C guy” instead of the NYU or AdaCore team, which also might have led to the borrowing of a preexisting GIGI layer.)

[Lucretia]

The *tree* packages in GNAT are autogenerated from a *def file, these map onto the C equivalent in the GCC backend so that GNAT can build the trees properly.

[Simon Wright]

"Dan'l Miller" <opt...@verizon.net> writes:

> 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)?

No one from AdaCore is commenting here about this, so what follows is my
view only.

For a start, the present GCC release naming scheme is, 8.0.0 is mainline
development in the initial phase; 8.0.1 is a release candidate; 8.1.0 is
a major release. I don't know what the last field is for after the major
release candidate, I've seen ARM use it for their own branch.

At the start of a new major release, AdaCore merge something like their
current state into GCC, very likely after some invisible-to-us
verification. There are two test suites: gnat and acats, where gnat is
maintained (again presumably) with their private repository. acats is an
old version of the official ACATS suite (2.5 vs 4.1g); I've been working
on bringing it up to date, see <https://github.com/simonjwright/ACATS>.

In GCC 8.1.0, ACATS4.1G reports

# of expected passes 2501
# of unexpected failures 11
# of expected failures 1452
# of unresolved testcases 11
# of unsupported tests 124

*** FAILURES: c250002 c611a04 c760a02 c760a03 cxag003 cxd1003 cxd1004
cxd1005 cxd2006 cxd3001 cxd3002

where

* c250002 is a UTF8 vs case-preserving fs vs extended characters in
filename issue (also fails on Windows)
* c611a04 (new) is to do with class-wide preconditions
* c760a0? (new) are to do with using a separate anonymous object in a
function return
* cxd* are almost certainly to do with this being a desktop system, so
Annex D isn't completely supported

I checked the changes made from 7.1 onwards at the Github mirror
<https://github.com/gcc-mirror/gcc/blob/gcc-7-branch/gcc/ada/ChangeLog>:

* 7.1 to 7.2, 8 changes
* 7.2 to 7.3, 17 changes

The problems I've reported myself have mostly been macOS- or bare
ARM-related: the macOS-specific ones are either to do with Darwin
handling of shared libraries or the case-preserving HFS+
filesystem. I've tended to avoid the early stages of a new release,
letting those who have server farms for the purpose do the initial check
on different architectures.

[R R]

I remember discussions (from the 90ies ?) that it would be possible to generate source code from the IR. If that generated source code had not any copyright (ie GPL), you would have a GPL-strip compiler GPL C/Ada-code to C/Ada-code without any copyright.

R

[Dan'l Miller]

But GPLv3's “Target Code” clauses were devised to overtly prohibit utilizing such techniques; the resulting IR and downstream derivative works are all GPLv3 (regardless of the original source code's license) if a GPLv3ed toolchain was utilized to produce the IR.

Btw, under nearly all licenses other than GPLv3, LGPLv3, and AGPLv3, this particular technique would still result in a derivative work of the original source code under U.S. copyright law, which would mean that the generated-from-IR source code would still have the exact same rights-to-copy license as the original source code (e.g., GPLv2, MIT, Apache, public domain), unless the IR was produced by a GPLv3 toolchain in which the original source code's license is overridden by GPLv3 instead. (GPLv3 increased the strength of the viral spread via the “Target Code” clauses. Likewise with the Runtime Exception for GPLv3, because the Runtime Exception revokes itself in certain situations, one of which is IR.)

[Dan'l Miller]

On Thursday, May 17, 2018 at 11:49:03 AM UTC-5, Dan'l Miller wrote:
> Wait, GNAT has its own full-fledged IR stage prior to deriving either GENERIC or GIMPLE from that GNAT IR?

On Friday, May 18, 2018 at 6:48:22 AM UTC-5, Lucretia wrote:
> The *tree* packages in GNAT are autogenerated from a *def file, these map onto the C equivalent in the GCC backend so that GNAT can build the trees properly.

The following PowerPoint presentation concurs with you, Luke:
https://www.slideserve.com/reed/the-structure-of-the-gnat-compiler

It also presents a rewording of my “Wait, …” comment above: GNAT builds an entire Ada-oriented AST-adorned-with-semantics then builds another IR tree using GCC-C-language-compiler constructs. Effectively GNAT works by effectively translating Ada IR to C IR internally, and then generating machine code from C's IR. I will need to investigate
1) whether C++ likewise builds its own AST-adorned-with-semantics then builds another IR tree using only C-language constructs
or
2) whether the so-called C-IR tree is actually capable of full-fledged C++-semantic adornment (i.e., whether the so-called C IR would be actually full-fledged C++ IR not lowered to C-only constructs at all) and thus C++ would build only one tree , not GNAT's two.

The GiggleVM drop-in LSP alternative to GIGI in GNAT would have the ability to translate Ada's AST-with-semantic-adornment to either C or C++ constructs in the interface-to-LLVM rear side of Clang. Occasionally, it might be convenient for GiggleVM to map Ada to directly analogous C++ constructs instead of to C to avoid reinventing the OO wheel from scratch, especially regarding Ada's tagged records vis a vis C++'s vtables.

I need to investigate those def files. Specifically I'll need to learn: where is the script/code that reads def files and generates C code or C macros to manipulate the C IR tree? Perhaps running these def scripts is a major portion of what you refer to as “GCC is a bitch to build” on your GCC build script GitHub README.md.

[Dan'l Miller]

On Friday, May 18, 2018 at 6:48:22 AM UTC-5, Lucretia wrote:

> The *tree* packages in GNAT are autogenerated from a *def file, these map onto the C equivalent in the
> GCC backend so that GNAT can build the trees properly.

Ahh, are these .def files the pre-C++ hack of using multiply-included C header files (without multiple-inclusion guard conditional compilation #if !defined NAME_OF_FILE) to emulate parameterized types? I guess I need to analyze the various points at which these .def files are #included to see if ”template” parameters are ginned up to be passed into the #include.

I would say that a human being author of a GiggleVM would only need a read-only* knowledge of these trees to mimic them over in rear-of-Clang-speak to feed LLVM the way that GIGI speaks rear-of-C/C++-GCC to feed GENERIC/GIMPLE. But the more that I think about it, perhaps a mechanized transliteration of GIGI's rear-of-GCC-C/C++-feeding-GENERIC/GIMPLE to GiggleVM's rear-of-Clang-feeding-LLVM-IR might assure fewer bugs (or at least bug-for-bug compatibility).

* Writing these GENERIC trees would require far deeper & broader full-grok knowledge.

[Brian Drummond]

On Fri, 18 May 2018 18:48:03 -0700, Dan'l Miller wrote:


>
> I need to investigate those def files. Specifically I'll need to learn:
> where is the script/code that reads def files and generates C code or C
> macros to manipulate the C IR tree? Perhaps running these def scripts
> is a major portion of what you refer to as “GCC is a bitch to build” on
> your GCC build script GitHub README.md.

I think you'll be reading a lot of AWK if you try.

One aspect of building gcc being such a bitch is that translation process
building a lot of *source* code (not only from the def files, but also
from other hooks in the sources that build a garbage collector) in the
*build* tree, which must therefore be kept completely separate from the
source tree (and makes "clean" and even "distclean" make targets flaky).

This comes back and bites you (well me, anyway) when debugging, when I
try unsuccessfully to trace a source code file/lineno reference, only to
find it's nonexistent ... in the source tree and I have to look elsewhere
for it.

It would be nice to have a clean separation of sources, generated
sources, and object files, but...

-- Brian

[Dan'l Miller]

Luke & Simon & anyone else, do you concur? Is this your experience?

If so, then I think we have arrived at the A#1 internal-technical reason why Apple et al pulled out of GCC to go author Clang (and why Flang community also is fleeing GCC). Licensing alone isn't what is driving Clang and Flang.

Actually, Brian, why doesn't an obvious demarcation exist where the generated C/C++-language sources are versus separate where the nongenerated C/C++-language sources are. (It is customary in most development communities to put the generated sources in some sort of different directory than src & include, which are reserved for the non-generated sources, plus often with some different file extension, e.g., .g.h and .g.c (i.e., g for generated) or something like that. I am going to have really delve into this to see the mess in the vicinity of the C IR tree (especially within GIGI) with my own eyes. Clean room (without referring to this mess) is always an option.

[Simon Wright]

Brian Drummond <br...@shapes.demon.co.uk> writes:

> This comes back and bites you (well me, anyway) when debugging, when I
> try unsuccessfully to trace a source code file/lineno reference, only
> to find it's nonexistent ... in the source tree and I have to look
> elsewhere for it.

Not directly related, but when exploring the compiler's innards (only
the Ada part, since the machine definition files etc. are way outside my
competence/area of interest) I've used a GPR like

project Gcc_8 is

for Source_Dirs use ("gcc-8.1.0-build/gcc/ada",
"gcc-8.1.0/gcc/ada");
for Object_Dir use "gcc-8.1.0-build/gcc/ada";
for Languages use ("Ada", "C");

end Gcc_8;

The build process selects/generates some Ada files from templates in
the source tree, gcc-8.1.0/gcc/ada, into the build tree,
gcc-8.1.0-build/gcc/ada; the Ada objects are compiled in the build tree.

I can then use Emacs ada-mode or GPS to explore the code.

One reason for needing to do this is the AdaCore fondness for "use". For
example, bindgen.adb's context clauses are

with ALI; use ALI;
with Casing; use Casing;
with Fname; use Fname;
with Gnatvsn; use Gnatvsn;
with Hostparm;
with Namet; use Namet;
with Opt; use Opt;
with Osint; use Osint;
with Osint.B; use Osint.B;
with Output; use Output;
with Rident; use Rident;
with Stringt; use Stringt;
with Table;
with Targparm; use Targparm;
with Types; use Types;

with System.OS_Lib;
with System.WCh_Con; use System.WCh_Con;

with GNAT.Heap_Sort_A; use GNAT.Heap_Sort_A;
with GNAT.HTable;

[Shark8]

On Saturday, May 19, 2018 at 7:04:12 AM UTC-6, Brian Drummond wrote:
>
> It would be nice to have a clean separation of sources, generated
> sources, and object files, but...

One of the things I was shooting for with Byron is zero "generated sources" -- the entire system being Ada 2012.

[Brian Drummond]

On Sat, 19 May 2018 08:04:00 -0700, Dan'l Miller wrote:

> On Saturday, May 19, 2018 at 8:04:12 AM UTC-5, Brian Drummond wrote:

>> It would be nice to have a clean separation of sources, generated
>> sources, and object files, but...
>>
>> -- Brian
>
> Luke & Simon & anyone else, do you concur? Is this your experience?
>
> If so, then I think we have arrived at the A#1 internal-technical reason

> why Apple et al pulled out of GCC ...

Don't know for sure, but as I posted previously, I suspect it's the main
obstacle even to something much simpler like porting Gnat Libre (gcc-x.y)
bugfixes to FSF Gnat (gcc-z.w) versions.

> Actually, Brian, why doesn't an obvious demarcation exist where the
> generated C/C++-language sources are versus separate where the
> nongenerated C/C++-language sources are.

You'd probably have to ask on one of the gcc mailing lists, but they are
somewhat sensitive places to voice a critical opinion.

I can only speculate that anyone who feels that way doesn't have enough
gcc skills to do anything substantial about it (that would include me)
while anyone with those skills was so far down the hole that the mess
seemed perfectly normal, or at least tolerable ... or maybe just less
unpleasant than the ramifications of trying to fix it via the opaque
autoconfigure/make build system.

So the demarcation is that those files have extensions .c, .h etc instead
of .o...

-- Brian

[Simon Wright]

Brian Drummond <br...@shapes.demon.co.uk> writes:

> On Sat, 19 May 2018 08:04:00 -0700, Dan'l Miller wrote:

>> Actually, Brian, why doesn't an obvious demarcation exist where the
>> generated C/C++-language sources are versus separate where the
>> nongenerated C/C++-language sources are.
>
> You'd probably have to ask on one of the gcc mailing lists, but they
> are somewhat sensitive places to voice a critical opinion.

I noticed this before .. aren't all the generated items in the build
directory?

[Lucretia]

On Sunday, 20 May 2018 14:00:29 UTC+1, Brian Drummond wrote:
> On Sat, 19 May 2018 08:04:00 -0700, Dan'l Miller wrote:
>
> > On Saturday, May 19, 2018 at 8:04:12 AM UTC-5, Brian Drummond wrote:
>
> >> It would be nice to have a clean separation of sources, generated
> >> sources, and object files, but...
> >>
> >> -- Brian
> >
> > Luke & Simon & anyone else, do you concur? Is this your experience?
> >
> > If so, then I think we have arrived at the A#1 internal-technical reason
> > why Apple et al pulled out of GCC ...
>
> Don't know for sure, but as I posted previously, I suspect it's the main
> obstacle even to something much simpler like porting Gnat Libre (gcc-x.y)
> bugfixes to FSF Gnat (gcc-z.w) versions.

It's publicly available, somewhere, but Apple wanted more control over the source and they wanted to be able to incorporate the compiler within xcode, which they couldn't do with GCC.

[Brian Drummond]

Yes. Or in whichever subdirectory of it the associated objects are.

Makes no sense to me.

-- Brian

[invalid]

On 2018-05-09, Randy Brukardt <ra...@rrsoftware.com> wrote:
> "Dan'l Miller" <opt...@verizon.net> wrote in message
> news:d690863e-e230-4188...@googlegroups.com...
> ...
>>4) RR Software's Janus Ada
>>?? Ada1995 plus partial Ada2005
>
> As of the preview last year, "partial Ada2012" (*very* partial) is also
> included. I'm hoping to get a release version of that out next month -
> possibly with more features if time permits.

What platform(s) do you support, and do you mind publishing the pricing for
a single-user?

[Randy Brukardt]

"invalid" <add...@is.invalid> wrote in message
news:slrnpj58ua....@is.invalid...

See www.rrsoftware.com, and specifically
http://www.rrsoftware.com/html/companyinf/prices.htm.

Note that the product is still called "Janus/Ada 95" 'cause calling it
"Janus/Ada 95/2007/2012" is too unwieldly. :-)

Randy.

[invalid]

There is mention of your product for 386 UNIX but I couldn't find any info
about which UNIX... could you clarify please? I have Solaris (UNIX) and
Linux (not UNIX) but no Windows boxes. It seems you're focusing on Windows?

Thank you.

[Randy Brukardt]

"invalid" <add...@is.invalid> wrote in message

news:slrnpjh539....@is.invalid...

We haven't supported the Unix versions for years. The primary OS was SCO
Unix (which I believe is defunct).

>I have Solaris (UNIX) and
> Linux (not UNIX) but no Windows boxes. It seems you're focusing on
> Windows?

Yes. We've occassionally considered doing a Linux version, but it's very
unclear there would be much of a market (GNAT is trivially available on most
Linux distributions).

Randy.

[invalid]

I guess the question is how many individuals (as opposed to companies) want
to sell proprietary software written in Ada and targeting Intel Linux? For
that set of people there is no reasonable alternative. There is usually a
gcc-ada, but like the rest of open sore software no guarantees and you're on
your own.