Aeonix Ada 95

Aeonix Ada 95

[suburb]

I am a software engineer for ITT Federal Services Corporation,
at Vandenburg Air Force Base, Calif. USA.  I have been assigned
the task of choosing an Ada compiler for my software team and
am seeking information on the Aeonix Ada 95 compiler.  I need
it to engineer software for real-time usage on an embedded
system with some tough timimg constraints.  I am soliciting for
information and opinions concerning this compiler.

Thank you.

Robert Niedermann
NiedermR@fsc1.vafb.af.mil
(805) 734-8232 x-63668

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet

Re: Aeonix Ada 95

[Robert Dewar]

iRobert Niederman says

<<I am a software engineer for ITT Federal Services Corporation,
at Vandenburg Air Force Base, Calif. USA.  I have been assigned
the task of choosing an Ada compiler for my software team and
am seeking information on the Aeonix Ada 95 compiler.  I need
it to engineer software for real-time usage on an embedded
system with some tough timimg constraints.  I am soliciting for
information and opinions concerning this compiler.
>>

You should also investigate GNAT. One aspect of GNAT that is significant
is that it is the only general purpose compiler that passes ALL (100%)
of the applicable tests in the real time annex. Check out the validation
reports on the IC host to verify this claim.

For what system are you looking for a compiler?

For information on commercial support for GNAT, send email to sales@gnat.com

Re: Aeonix Ada 95

[Tom Moran]

>> embedded system with some tough timimg constraints
> GNAT ... only general purpose compiler that passes ALL (100%)
> of the applicable tests in the real time annex
  Do all versions of GNAT do all the real time stuff in an embedded
system context?  The original poster did not specify his target system.

Re: Aeonix Ada 95

[Dave Wood]

Tom Moran wrote:
> 
> >> embedded system with some tough timimg constraints
> > GNAT ... only general purpose compiler that passes ALL (100%)
> > of the applicable tests in the real time annex
>   Do all versions of GNAT do all the real time stuff in an embedded
> system context?  The original poster did not specify his target system.

I can't respond to the original poster due to conflict
of interest, but we have validated the real-time annex
just recently for our first ObjectAda Real-Time compiler
(for Intel targets).  PowerPC is following shortly.  I'm
pretty sure others have validated the real-time annex for
real-time targets (Green Hills?)

GNAT is not validated for *any* real-time targets, is it?

-- Dave Wood
-- Product Manager, ObjectAda for Windows
-- Aonix - "Ada with an Attitude"
-- http://www.aonix.com

Re: Aeonix Ada 95

[Robert Dewar]

Dave Wood wrote

  <<I can't respond to the original poster due to conflict
  of interest, but we have validated the real-time annex
  just recently for our first ObjectAda Real-Time compiler
  (for Intel targets).  PowerPC is following shortly.  I'm
  pretty sure others have validated the real-time annex for
  real-time targets (Green Hills?)>>

Well I don't think there is any conflict of interest here, except
in the normal sense of competition! But anyway, I certainly don't
want to create incorrect impressions, so let me say exactly what
I was talking about.

First, there is no such think as "validating the real-time annex",
at least not with version 2.0.1 of the ACVC. There is only one
overall validation status, and for anything else you have to study
the results in detail. The validation simply reports which tests
pass, which tests fail, and which tests are inapplicable. There
are three reasons for tests being inapplicable:

  1. The test is plain wrong in a particular environment. For instance, in
     one of our upcoming validations, on a cross-target with no I/O, three
     tests expect Name_Error to be raised when opening a non-existent file,
     when clearly Use_Error is allowed by the RM. The (perfectly reasonable)
     resolution here was that these tests should be considered as passing
     in this environment if Use_Error is raised, since the RM specifically
     allows for the raising of Use_Error in such a case.

  2. The tests is testing for some implementation variation that is not
     relevant to the current implementation. For example, there are a
     whole lot of IO tests that carefully insist that *if* you have, as
     allowed, a very small limit on the range of Count, then you properly
     raise various exceptions. But in practice most implementations make
     Count derived from Integer, so these tests are inapplicable and that
     is a good thing!

  3. The test is ruled inapplicable for a given validation as a result of
     an appeal to RM 1.1.3(6):

       6  Contain no variations except those explicitly permitted by this
          International Standard, or those that are impossible or
          impractical to avoid given the implementation's execution
          environment;

     The impossible or impractical phrase is of course a subjective standard,
     that is potentially tricky to judge. Two examples from current reported
     validations are:

       The AONIX compiler for NT only implements 7 levels of priorites because
       there are only 7 levels of task priorities provided in NT, so if you
       are maping priority levels one-to-one, the requirement of 31 levels
       of priority cannot be met.

       The Greenhills compiler for VxWorks does not pass the Annex D tests
       that test for strict conformance with the dispatching model of annex
       D. That is because VxWorks has subtly "wrong" semantics from the
       point of view of annex D.

     Actually I am not quite sure about the Greenhills case, I think these
     tests may be considered not supported, rather than inapplicable. The
     line between these two categories is a delicate one, so best to look
     at the actual test reports in the VSR's to determine exactly which
     tests pass and which do not.

As far as other compilers go, I have not looked carefully at the validation
profile of the embedded x86 product from Aonix. It lists two inapplicable
tests, but I do not know if these are 1.1.3(6) cases or not, if not, then
my statement is certainly not correct with respect to this validation, and
I apologize for the mistake. The validated compilers list changes all the
time (a good thing!) so any statement about its state is likely to become
false with the march of time.

When I said that GNAT passed the real time annex I meant that it did so
without appealing to RM 1.1.3(6). Our position is to provide at least a
mode in which annex D requirements are met completely. In the case where
there is a clash between the underlying OS thread semantics and the
requirements of annex D, we provide a choice between following annex D
exactly, or just taking whatever you get from the underlying threads.

Now one EXTREMELY IMPORTANT point is that it is perfectly possible to use
a compiler with deviations from the standard. This is PARTICULARLY true in
the case of annex D, since relatively few applications will depend on the
details of the annex D semantics. After all in Ada 83, all such details
were implementation defined, and yet many applications successfully used
tasking (of course many applications also avoided the use of tasking because
of the lack of definition, and we hope that the deterministic semantics of
annex D will bring some of these applications back into the tasking fold :-)

For example, the Greenhills compiler is the only off-the-shelf VxWorks
compiler today (although perhaps that statement too will be obsoleted
soon). Many Vxworks users would actually prefer that their Ada compiler
follow the VxWorks semantics, and indeed as a default dispatching policy,
this is reasonable, but you cannot expect to get accurate
FIFO_WITHIN_PRIORITIES behavior in this environment (and indeed the
compiler should reject the attempt).

Dave Wood will remember that I was one of the people who most vociferously
argued that the inability on NT to support 31 levels of priority should
not be considered too negatively, since for many applications you WANT
the 1-1 mapping, and you can't have both 31 levels of priority and this
1-1 mapping (complaints to Microsoft, not here!) However, I was not
arguing that 7 = 31! If you have an application (RMA scheduling is
a typical case which results in such a requirement) that requires 31
levels of priority then you will be out of luck, and your perfectly
valid Ada 95 program will not run.

Now I would assume that the embedded version of the compiler does not have
this limitation of 7 priority levels, so very probably it does NOT have to
rely on 1.1.3(6), and thus in thesense I was talking about DOES fully
support Annex D on a general purpose platform. As I said, my validation
knowledge was a little out of date (a state which I certainly hope will
frequently be the case as new targets are validated!)

The lesson to be learned from this discussion is that everyone seriously
using a compiler should study the validation results in detail. Especially
where there are 1.1.3(6) variations claiming variations not explicitly
permitted by the RM, other than by virtue of this clause, it is important
for users to understand the limitations. In some cases, these limitations
can cause programs to silently malfunction even though they are 100%
correct Ada 95. For example, if you have two tasks A and B, where A has
priority Priority'First + 6 and B has priority Priority'Last - 6, then
Ada semantics says that task B has a greater priority than A, but in
an environment with only 7 levels of priority, the priorities will be
silently reversed. This is a constructed example, and in the particular
case of 7 levels of priority, it seems pretty unlikely that this would
arise. However 1.1.3(6) has no language about the resulting variations
being detected easily, or being unlikely to cause trouble, so it is 
definitely a buyer beware situation here.

Going back to the GNAT validations. Ada Core Technologies has made a policy
decision that we will only do validations in which we fully support the
language (no unsupported tests in the VSR), and where inapplicable tests
never appeal to 1.1.3(6), i.e. the only reasons for tests being inapplicable
are cases 1 and 2 described above.

We accomplish this goal by two methods:

  1. If we cannot validate under these conditions in a given environment,
     we simply don't validate. Now of course commercial pressures might
     cause us to change this viewpoint (money talks!) but so far we have
     not had to relax this position.

  2. Where there is a clash between the underlying threads model of the
     operating system, we provide a choice of threads models, the user
     either has the choice of using the OS thread model, with its
     limitations, or of using our own thread model which is exactly
     annex D compliant.

     We prefer that the threads model provided by the OS be exactly right,
     and for cases where we have some technical interaction (SGI, RTEMS,
     Tenon Machten), this can be achieved. But in other cases (notably
     Solaris), we need to offer the choice of threads models. The choice
     of the annex D thread model is made either automaticaly if a pragma
     is used indicating the requirement, or as a result of a compiler
     option.

We certainly are NOT saying that compilers that appeal to 1.1.3(6) are
in any sense unusable. As I mentioned earlier, I was one of the really
strenuous arguers that the NT limitation I discussed above is one that
should be allowed under 1.1.3(6), even though it is perfectly possible
to provide exact annex D semantics on NT. In fact I think I can fairly
say that without my arguments on behalf of the Aonix petition in this
matter, the decision might easily have been made the other way!

It is often the case that a compiler is fully usable even if it implements
NONE of the real time (or any other) annex, in a particular situation. So
certainly any implication that a compiler is unusable just because there
is a single feature unsupported is total nonsense.

However, here at Ada Core Technologies, we think it makes things simpler
for users if they can get an ACT validated compiler and know that they
do not have to worry about 1.1.3(6) issues, and that if something is
required to be supported in the RM (as opposed to being explicitly
optional, or implementation advice), then they can count on the fact
that there are no intentional 1.1.3(6) deviations.

Dave, what would be useful, and would help clear up any confusion I may
have caused, is for you to quickly summarize the details of the
inapplicable tests in the embedded validation.

For the record, the inapplicable tests in the GNAT annex D validations
correspond to the non-implementation of the asynchronous task capability.
This capability was explicitly made optional in the RM, recognizing that
it is unlikely to make sense in other than bare target environments.

Robert Dewar
Ada Core Technologies

Re: Aeonix Ada 95

[Dave Wood]

Gadzooks!  Where do you find the time for such lengthy posts?  :-)


Robert Dewar wrote:
> 
> Dave Wood wrote
> 
>   <<I can't respond to the original poster due to conflict
>   of interest, but we have validated the real-time annex
>   just recently for our first ObjectAda Real-Time compiler
>   (for Intel targets).  PowerPC is following shortly.  
> 
> Well I don't think there is any conflict of interest here, except
> in the normal sense of competition! But anyway, I certainly don't
> want to create incorrect impressions, so let me say exactly what
> I was talking about.

Just a point of clarification.  What I was saying was that I 
wouldn't respond to the original query (I forget who posted it),
because I don't wish to engage in blatant advertising on c.l.a.
I wasn't referring to your post, Robert, which followed the
original.  In fact, yor message was deleted from our server and
so I never even had the chance to read it.

[snip]

> 
>        The AONIX compiler for NT only implements 7 levels of priorites because
>        there are only 7 levels of task priorities provided in NT, so if you
>        are maping priority levels one-to-one, the requirement of 31 levels
>        of priority cannot be met.

[snip]
 
> As far as other compilers go, I have not looked carefully at the validation
> profile of the embedded x86 product from Aonix. It lists two inapplicable
> tests, but I do not know if these are 1.1.3(6) cases or not, if not, then
> my statement is certainly not correct with respect to this validation, and
> I apologize for the mistake. The validated compilers list changes all the
> time (a good thing!) so any statement about its state is likely to become
> false with the march of time.
> 
> When I said that GNAT passed the real time annex I meant that it did so
> without appealing to RM 1.1.3(6). Our position is to provide at least a
> mode in which annex D requirements are met completely. In the case where
> there is a clash between the underlying OS thread semantics and the
> requirements of annex D, we provide a choice between following annex D
> exactly, or just taking whatever you get from the underlying threads.
> 
> Now one EXTREMELY IMPORTANT point is that it is perfectly possible to use
> a compiler with deviations from the standard. This is PARTICULARLY true in
> the case of annex D, since relatively few applications will depend on the
> details of the annex D semantics. After all in Ada 83, all such details
> were implementation defined, and yet many applications successfully used
> tasking (of course many applications also avoided the use of tasking because
> of the lack of definition, and we hope that the deterministic semantics of
> annex D will bring some of these applications back into the tasking fold :-)
> 
> Dave Wood will remember that I was one of the people who most vociferously
> argued that the inability on NT to support 31 levels of priority should
> not be considered too negatively, since for many applications you WANT
> the 1-1 mapping, and you can't have both 31 levels of priority and this
> 1-1 mapping (complaints to Microsoft, not here!) However, I was not
> arguing that 7 = 31! If you have an application (RMA scheduling is
> a typical case which results in such a requirement) that requires 31
> levels of priority then you will be out of luck, and your perfectly
> valid Ada 95 program will not run.
> 
> Now I would assume that the embedded version of the compiler does not have
> this limitation of 7 priority levels, so very probably it does NOT have to
> rely on 1.1.3(6), and thus in thesense I was talking about DOES fully
> support Annex D on a general purpose platform. As I said, my validation
> knowledge was a little out of date (a state which I certainly hope will
> frequently be the case as new targets are validated!)

Very thoroughly stated.  To answer the issue, the validation in 
question is not the NT native compiler ("ObjectAda for Windows"),
but rather the cross compiler targetting Intel running the Phar Lap
ETS kernel ("ObjectAda Real-Time for Windows x Intel/ETS" - an 
ungodly long name, but such is required when you're talking about
cross compilers and you hope for some level of precision...)  

The ETS kernel indeed eradicates the restrictions of NT with 
regard to priority levels and also provides for other
performance characteristics (like deterministic scheduling and minimal
latency) and interface characteristics (like on-chip peripheral drivers
and support for various i/o devices) typically expected and required 
for hard real-time and embedded applications.  

While NT is generally not suitable for hard real-time applications,
it's a great platform for development when targetting ETS because
the ETS kernel uses the Win32 OS interface, which makes it very 
easy to accomplish early and inexpensive prototyping on the host 
environment before the target hardware is available for testing.

In fact, it takes more to make a good cross development platform
than just to validate a compiler - you need to deliver it along with
a well-considered environment and set of tools suited to the task,
like board customization packages, rate monotonic analysis tools,
on-target debugging, and fully-integrated linking/ locating/
dowloading capabilities.

OK, so maybe I can do a *little* blatant advertising.  :-)

> The lesson to be learned from this discussion is that everyone seriously
> using a compiler should study the validation results in detail. 

I couldn't agree more - you have to be sure the compiler supports
the features that you need.  It's a sad fact that there are a
significant number of "validated" Ada 95 compilers out there that
don't pass a single Ada 95 test, a situation that will be rectified
with ACVC 2.1.  It's safe to say that there are unvalidated 
compilers (like GNAT) that support far more Ada 95 than some
validated compilers (like those from, er, well, nevermind...)

By all means, people should peruse the validated compiler listings
(and test results contained therein) before making a decision that
will have long-term cost implications.

-- Dave Wood
-- Product Manager, ObjectAda for Windows
-- Aonix - "Ada with an Attitude"
-- http://www.aonix.com

Re: Aeonix Ada 95

[Robert Dewar]

<<Gadzooks!  Where do you find the time for such lengthy posts>>

I type fast, and I keep a window open for email and news stuff, and type
in it when I don't have anything else to do :-)

Re: Aeonix Ada 95

[Robert Dewar]

Dave Wood asks

<<GNAT is not validated for *any* real-time targets, is it?>>

Well I am not quite sure I understand this question. Certainly for example,
SGI considers that IRIX is usable for a wide range of real time applications,
and for example JEOL is successfully using GNAT for real time applications
in the medical instrumentation field, and we have many other customers
doing hard real time applications using validated versions of GNAT.

Perhaps what dave meant to say here was embedded or perhaps cross targets,
in which case the answer is no, not yet. We expect to complete our first
cross-validation in the next couple of weeks, and we will let you know
when that is successfully completed!

Robert Dewar
Ada Core Technologies

Re: Aeonix Ada 95

[Robert Dewar]

Tom Moran said

<<  Do all versions of GNAT do all the real time stuff in an embedded
system context?  The original poster did not specify his target system.>>

Well there are versions of GNAT done by volunteers that have nothing to
do with us (Ada Core Technologies), so certinly the anwer is NO. MOre
specifically, I was talking about validated versions, and as I noted
in my post, there are no validated versions of GNAT for embedded systems
yet (a situation which will change very shortly!)

Re: Aeonix Ada 95

[Robert I. Eachus]

In article <dewar.858351614@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

  > This reminds me of a question that Phillipe Kruchten asked me,
  > back in his prerational days when he worked on the Ada-Ed project
  > at NYU.

  Hmmm... Phillipe wasn't rational when he was at NYU?  ;-)

  > He asked if he could be validated as an Ada 83 compiler. He proposed to
  > look at each C test, think for a bit, and then say Passed!

  If he could pass the B-tests, I'd be willing to give him a
certificate.  (For those who have never dealt with the ACVC, the
B-tests are--in 1.x--about 1000 test which not only require you to
find every error at compile time, but to diagnose it correctly.  Some
tests have/had hundreds of errors. Every compiler vendor I know spent
most of their effort during validation getting the B-tests right.
Most of the rest was spent on C-tests, and A,D,E and L collectively
accounted for at most 1-2% of the effort.)

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Aeonix Ada 95

[Robert Dewar]

Robert Eachus said

<<  If he could pass the B-tests,
certificate.  (For those who have never dealt with the ACVC, the
B-tests are--in 1.x--about 1000 test which not only require you to
find every error at compile time, but to diagnose it correctly.  Some
tests have/had hundreds of errors. Every compiler vendor I know spent
most of their effort during validation getting the B-tests right.
Most of the rest was spent on C-tests, and A,D,E and L collectively
accounted for at most 1-2% of the effort.)>>

First of all, there is no requirement that you diagnose the error correctly,
merely that you output an error message that refers to the affected line,
it would be fine as far as the ACVC is concerned to simply flag every
error line with a message that said ERROR.

Given that every line has a comment on it that says ERROR, I have no doubt
that the amazing Kruchten compiler would be able to read through a B test
and announce ERROR on all appropriate lines :-)

Re: Aonix Ada 95

[Keith Allan Shillington]

> Robert Eachus said
> ...  (For those who have never dealt with the ACVC, the
> B-tests are--in 1.x--about 1000 test which not only require you to
> find every error at compile time, but to diagnose it correctly.  Some
> tests have/had hundreds of errors. Every compiler vendor I know spent
> most of their effort during validation getting the B-tests right.
> Most of the rest was spent on C-tests, and A,D,E and L collectively
> accounted for at most 1-2% of the effort.)

Me thinks your numbers are overly pessimized, but, that is all in the past
anyway.  Anyone who bothers to look at the 2.X ACVC suite will find a
stronger emphasis on C and L tests.  It was our expectation in writing them
that the vendors would find a little more need to focus on the implementation
of the executable bits.  And, let us not discount the value of a good error
message from a compiler.

Robert Dewar deftly points out:

<<Given that every line has a comment on it that says ERROR, I have no doubt
that the amazing Kruchten compiler would be able to read through a B test
and announce ERROR on all appropriate lines :-)>>

Takes me back to the days of the Basic interpreter that was possessed of the
single error message: "Huh?"

Re: Aeonix Ada 95

[Chris Morgan]

In article <dewar.858097255@merv> dewar@merv.cs.nyu.edu (Robert Dewar)
writes:

> 
> <<Gadzooks!  Where do you find the time for such lengthy posts>>
> 
> I type fast, and I keep a window open for email and news stuff, and type
> in it when I don't have anything else to do :-)
> 

How many priority levels do you support, what is your interrupt
latency and are you validated?
-- 
Chris Morgan (cm@mihalis.demon.co.uk)

Re: Aeonix Ada 95

[Robert Dewar]

Chris asks

<<How many priority levels do you support, what is your interrupt
latency and are you validated?>>

This reminds me of a question that Phillipe Kruchten asked me, back in his
prerational days when he worked on the Ada-Ed project at NYU.

He asked if he could be validated as an Ada 83 compiler. He proposed to
look at each C test, think for a bit, and then say Passed!

:-)

Human compilers (was: Re: Aeonix Ada 95)

[Norman H. Cohen]

Robert Dewar wrote:

> This reminds me of a question that Phillipe Kruchten asked me, back in his
> prerational days when he worked on the Ada-Ed project at NYU.

Surely you mean his "pre-Rational" days.  Sometimes capitalization makes
a big difference! :-)
 
> He asked if he could be validated as an Ada 83 compiler. He proposed to
> look at each C test, think for a bit, and then say Passed!
> 
> :-)

Perhaps he could be validated as an Ada-83 interpreter, but not as a
compiler.  Phillipe, don't give up your day job! :-)

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: Human compilers (was: Re: Aeonix Ada 95)

[Robert Dewar]

Norman said

<<Surely you mean his "pre-Rational" days.  Sometimes capitalization makes
a big difference! :-)>>

OOPS, I forgot the BEGIN JOKE and END JOKE keywords once again (we have
to be precise about such things for the formalists :-) :-)