From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c7fe97e7d36f4c57 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-03-08 20:47:22 PST Newsgroups: comp.lang.ada Path: bga.com!news.sprintlink.net!uunet!world!pazy From: pazy@world.std.com (Offer Pazy) Subject: Re: Real-time implications of Ada 95 OO features Message-ID: Organization: The World Public Access UNIX, Brookline, MA References: <3jk9ba$dbe@ixnews3.ix.netcom.com> Date: Thu, 9 Mar 1995 03:45:20 GMT Date: 1995-03-09T03:45:20+00:00 List-Id: 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