Re: Aeonix Ada 95

[dewar@merv.cs.nyu.edu (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