Re: Green Hills Ada library question (Ada on VxWorks)

[Jim Chelini <jchelini@ma.aonix.com>]

dewarr@my-dejanews.com wrote:
> 
> In article <98092209530702@psavax.pwfl.com>,
>   "Marin David Condic, 561.796.8997, M/S 731-96" <condicma@PWFL.COM> wrote:
> > dewarr@MY-DEJANEWS.COM writes:
> > >One interesting question here is whether you need tasking,
> > >or whether a minimal runtime system, of the kind that would
> > >typically be used in a safety-critical system, would be
> > >usable. One approach that some of our customers are exploring
> > >is the use of our GNORT (GNAT No Run-Time) technology that
> > >provides a subset of Ada which generates absolutely ZERO
> > >bytes of runtime. This means that you can simply generate
> > >object files and then run them to the bare board using
> > >whatever low level toolset is appropriate.
> > >
> > >One customer for example is using OS/2 as the development
> > >environment, and then GNORT for actual delivery to the
> > >target system (which is a bare board x86).
> > >
> >     I'm curious about GNORT. Does the "zero bytes of runtime" mean
> >     that there are no compiler supplied procedures or functions that
> >     are ever called to do some common task? By which, I mean something
> >     like common code that does a bounds check and raises an exception,
> >     or something similar. I do  not mean something like the standard
> >     libraries for math functions, etc. (Those you can possibly treat
> >     as regular packages as if you wrote them yourself, provided you
> >     have enough information about the actual implementation) All the
> >     code for whatever statements are compiled is generated as some
> >     in-line machine code?
> >
> >     If you were to allow for subroutines for common operations like
> >     bounds checking, would there be any difference in providing
> >     subroutines for more complex features, such as task scheduling?
> >     (Other than the possible non-determinism. I'm thinking that a
> >     run-time library is not necessarily evil if it results in smaller
> >     code by sharing some frequently repeated operations and the
> >     tradeoff between procedure call overhead and space savings is
> >     reasonable.)
> >
> >     Just curious about how this stuff is done...
> >
> >     MDC
> 
> Right, there are NO runtime routines of any kind. All code
> is generated inline. No one is saying that a run-time library
> is evil, the problem is that in a certified environment you
> have to use a certified run-time.

Robert is correct here. In a safety critical application, the runtime 
must be certifable to the same level of assurance as the application.

> 
> Not only is it expensive to certify a run-time, an expense
> that is inevitably passed on to the user, but in any case it
> is preferable to not have to rely on some separate
> certification procedure, but instead to certify all your
> own code, and have that be the only code that needs
> certifying.

The above statement is a little confusing.  There are several points to
consider
1. > Not only is it expensive to certify a run-time, an expense that is
inevitably passed on to the user
2. >preferable to not have to rely on some separate certification
procedure
3. >certify all your own code,
4. >have that be the only code that needs certifying.

Point 1:
There is an expense to provide certification evidence for a runtime and 
given it is a commercial product (just like the compiler) the cost of
that product is passed to the user.  Typically, the cost for the user to
create this type of evidence greatly exceeds the cost of the COTS
package. 

Point 2:
There is no seperate certification procedure.  If we take the avionics
domain as an example, there is a single process for software
certification - DO-178B.  Now, software on its own can not be certified,
it must be part of an avionics function - hardware and software that
perform a specific function(s), i.e., a braking system, GPS, etc.

Point 3:
The generation of certification evidence for the runtime, must follow
the same procedures as the application.
The use of in-lining the "runtime" with the application shifts the
burden of certification of "runtime" elements from the vendor to the
user.  The user must now explain what the in-lined code does and ensure
it is correctly used.  For a Level A system, this would include
structural (coverage) testing to the machine code level.  For a runtime,
the burden of proof is on the vendor who must submit the certification
materials to the customer's experts (and sometimes national
certification authorities, FAA) for review and acceptance.  The vendor
should warrent these materials to meet the certification requirements.

Point 4:
A good compiler environment will include a linker capable of removing
unused functions, thereby giving the user only the code they need.  The
use of a certifiable runtime then leads to an application with complete
life cycle data for the runtime features used by the given application -
no more.  When the application is updated (which is normal given the
long life of the applications), if new runtime elements are included -
the evidence is still available, reducing costs to the program in later
phases.  

> 
> GNORT is certainly not for everyone, it is specifically
> intended for meeting the needs for safety critical
> certified code at a relatively modest cost, compared to
> the use of certified run-times.

See above points.  There are pros and cons on both sides but the user
should be aware of what they are signing up for.


> 
> -----== Posted via Deja News, The Leader in Internet Discussion ==-----
> http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum