TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Mark Lundquist <[log in to unmask]>
Reply To:
Mark Lundquist <[log in to unmask]>
Date:
Fri, 29 Oct 1999 07:57:18 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (105 lines)
From:  Ben Brosgol <[log in to unmask]>
t)

> "Vanilla" Java clearly has a number of problems with respect to determinstic
> real-time performance [...]  Nevertheless the language's very high
> degree of portability and safety (more than Ada's in > fact) have
> sparked interest from the real-time community.

Java and Ada offer rather different approaches to "portability", and
it's possible that the Java flavor is more closely aligned to the needs
of real-time/high-integrity system designers.

First, the Ada case:

    1) In the original DoD Ada effort, the portability benefits were mainly
       due to:

        - the language being well-defined
        - the definition being codified as a standard
        - validation

       The language definition itself also built in a certain amount of
       target independence, but perhaps more importantly, these
       surrounding provisions secured portability across compilers.
       In those days, compiler dependencies apparently were a bigger
       problem than they are today, when other languages have "caught
       up", at least to some degree, in terms of standardization.

       Compiler dependencies are still a problem.  Right now I'm writing
       some C++ code and I keep running into things that the Sun
       compiler doesn't grok.  One advantage Ada still has is the high
       degree of stability of its standards: one revision in the 16
       years so far since the original standard.  Other languages have
       "cycle times" that are much shorter.  For C++, the reasons for
       this should be fairly obvious to anyone familiar with the
       language.  For Java, the reasons are more complex.

    2) The choices of things Ada allows to be implementation dependent
       reveals a bias toward compiler targetability.  It was important
       that it be possible to make an Ada compiler for anything from a
       Cray to a Nintendo Game Boy.  It wouldn't have been acceptable
       for the language to be defined in such a way that broad classes
       of target architectures would turn out to be unsuitable for Ada.

       This value of the Ada design has sometimes been mistakenly spoken
       of as "portability".  From the implementor's point of view,
       there is an appearance of "portability" because it is easier to
       port the compiler to novel architectures.  It's really the
       compiler that is made more "portable", not application code.
       This ease of targetability actually competes against
       "deterministic" cross-target portability at the application
       level.  With consolidation of architecture features, the trend
       toward COTS in defense, etc., there are fewer truly weird
       architectures around, so ease of targetability begins to have
       less value.  (The x86 is pretty weird all right, but ubiquity has
       to count for something :-)

In Java, very little if anything is left to the implementation.  One
reason is that the language is designed for just one target: the JVM.
So things like the size of types and the floating point model are
pegged.  Native code Java compilers are a relative innovation, and there
you're really emulating the JVM in native code.  Another factor is the
philosophy that what you see at the source text level is very close to
the run time model, which might account for such things as order of
evaluation being specified.  I'm trying to think of things that Ada
leaves up to the implementation but are pegged in Java... what else is
there?  Parameter passing is by copy for primitive-type objects, and N/A
for class objects due to Java's by-reference semantics.

In Ada, it's very clear what things you are and are not allowed to
depend on.  That's good as far as it goes, but the real trouble is that
you might be depending on something without knowing it.  The advantage
of having everything nailed down is in the abatement of the Law of
Unintended Consequences, and this is certainly a good thing for
high-integrity systems.

So, what are the issues involved in putting Ada on equal footing with
Java in the areas where Java has the lead in portability?

    - Standard sized types.  They are already there, of course -- in
      package Interfaces.  Unfortunately, they're kind of "buried" there
      in keeping with the philosophy that sized integer types are of
      value for interfacing to hardware or other languages.  Regardless
      of where sized types are declared, code rule checkers can be used
      to check that integer types from Standard are not used.

    - Could there be a standardized "profile" of certain
      implementation-specifics (e.g. some Annex M stuff + ?)

    - Standard storage pools?

    - How would all this relate to Annex H?

    - ???...


--

Mark Lundquist
Senior Software Engineer
Rational Software
Development Solutions Business Unit
UNIX Suites Group
Aloha, OR, USA

ATOM RSS1 RSS2