comp.lang.ada
 help / color / mirror / Atom feed
From: pazy@world.std.com (Offer Pazy)
Subject: Re: Real-time implications of Ada 95 OO features
Date: Thu, 9 Mar 1995 03:45:20 GMT
Date: 1995-03-09T03:45:20+00:00	[thread overview]
Message-ID: <D55MFK.GIM@world.std.com> (raw)
In-Reply-To: 3jk9ba$dbe@ixnews3.ix.netcom.com

To the best of my knowledge, no such study has been carried out, at least
not within the design team. I could envision two areas where there might be
effects on real-time analysis and scheduling:

1. The additional overhead (in most unoptimized casees) involving
   dispatching. You will most likely need to go through an address table
   and then jump to the approriate subroutine.  In my view, this should not
   affect real-time programs since it merely adds a constant overhehead
   which is easily measured and factored into the formulas. Looking at a
   large Ada program as a whole, I would not think that this source of
   overhead is a significant one (relatively).

2. The second aspect, is the ability to prform pre-runtime scheuling
   analysis and determining possible paths in the program. With late
   binding, this problem becomes more complex since you can't see in the
   code exactly "where you are going".  The fact that no compile-time
   information exists to determine the path that wil be taken eventually,
   will also make it harder for tools to process such a program.  (By the
   way, I don't know of any tools that does this sort of an analysis on a
   polymorphic code; if someone has information about such tools, please
   post or e-mail me.) As a result, you will probably have to factor in the
   worst case scenario, i.e. choose the longest operation in each case.
   It's not ideal, but I think people use this worst-case method quite
   often, anyway.

On a side note: Some of Ada 95 "real-time" features are based on the OOP
features. At the start of the project, there was much debate whether or not
to go this route (that is, use OOP for real-time, or enhance the real-time
features independently of OOP).  I guess, altimately, we've picked some
middle ground (there were much more radical ideas orginally). The areas of
scheduling and time management, are largely void of OOP, but features such
as storage pool and finalization which may be critical for the reliability
(and determinism) of some real-time systems, use tagged types and
dispatching.  I guess the jury is still out as to whether this was a good
approach.  My own opinion is that "yes", it might delay a bit the
introduction of high-quality (in this area) compilers, but for the long
run, it will make Ada much more consistent and reliable.  But I'm
digressing.

Offer





      reply	other threads:[~1995-03-09  3:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1995-03-01  1:31 [Q] Relationships between tagged types John Woodruff
1995-03-03 14:44 ` Tucker Taft
1995-03-08 12:52   ` Real-time implications of Ada 95 OO features Will Stewart
1995-03-09  3:45     ` Offer Pazy [this message]
replies disabled

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