comp.lang.ada
 help / color / mirror / Atom feed
From: Dave Wood <dpw@aonix.com>
Subject: Re: Aeonix Ada 95
Date: 1997/03/10
Date: 1997-03-10T00:00:00+00:00	[thread overview]
Message-ID: <3324EFFF.4261@aonix.com> (raw)
In-Reply-To: dewar.858002073@merv


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




  reply	other threads:[~1997-03-10  0:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-03-09  0:00 Aeonix Ada 95 suburb
1997-03-09  0:00 ` Robert Dewar
1997-03-09  0:00   ` Tom Moran
1997-03-09  0:00     ` Dave Wood
1997-03-10  0:00       ` Robert Dewar
1997-03-10  0:00         ` Dave Wood [this message]
1997-03-11  0:00           ` Robert Dewar
1997-03-10  0:00       ` Robert Dewar
1997-03-11  0:00     ` Robert Dewar
1997-03-17  0:00     ` Robert I. Eachus
1997-03-17  0:00       ` Robert Dewar
1997-03-21  0:00         ` Aonix " Keith Allan Shillington
1997-03-14  0:00   ` Aeonix " Chris Morgan
1997-03-14  0:00     ` Robert Dewar
1997-03-17  0:00       ` Human compilers (was: Re: Aeonix Ada 95) Norman H. Cohen
1997-03-19  0:00         ` Robert Dewar
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox