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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,2ccbce6c5ad05bfd
X-Google-Attributes: gid103376,public
From: Richard Riehle <rriehle@nunic.nu.edu>
Subject: Re: Can OO be successful in real-time embedded systems?
Date: 1996/05/13
Message-ID: <Pine.GSO.3.92.960513041740.10150A-100000@nunic.nu.edu>#1/1
X-Deja-AN: 154574861
references: <m0uHHBP-0000ztC@crash.cts.com> <Dr58I4.6Go@world.std.com>
 <3191DE76.130F@lmtas.lmco.com>
 <Pine.GSO.3.92.960509164924.1191A-100000@nunic.nu.edu>
 <Dr702w.50H@world.std.com>
to: Robert A Duff <bobduff@world.std.com>
content-type: TEXT/PLAIN; charset=US-ASCII
organization: National University, San Diego
mime-version: 1.0
newsgroups: comp.lang.ada
Date: 1996-05-13T00:00:00+00:00
List-Id: <comp.lang.ada>


On Fri, 10 May 1996, Robert A Duff wrote:

> In article <Pine.GSO.3.92.960509164924.1191A-100000@nunic.nu.edu>,
> Richard Riehle  <rriehle@nunic.nu.edu> wrote:
> >   However, in hard, real-time systems (HRTS), run-time dispatching is a
> >   little more of an issue than a simple case statement.  The controlling
> >   factor is whether we can predict that a certain sequence of actions
> >   will be time-determinate.
>
> What exactly do you mean by "a little more of an issue"?  The actual
> dispatching call can be done in constant time, just like a case
> statement does a jump through a table in constant time.  So the *only*
> difference is what I mentioned in my previous post: with a case
> statement, you have all the alternatives sitting there in one place,
> whereas with a dispatching call, they are scattered all over.  Do you
> see any *other* differences between case statements and dispatching,
> that would affect the ability to do worst-case timing analysis?

  Agreed that in small programs where the classwide operations are in
  the same package as the base type, there should not be too much
  of a problem with evaluation of timing.  As we override operators
  and add new classwide operators, it is going to become more difficult
  to do them kinds of timing analysis one can do with a simple case
  statement.

  One model for classwide operations will be something like:

       package Q is
          type T is tagged ...
          ...
       end Q;

       package Q.Classwide is
         procedure P1 (X : T'Class);
         procedure P2 (X : T'Class);
         ...
       end Q.Classwide;

  Now we have derivations of T, complete with overriding operations.  The
  Ada 95 model for this is crisp, clean, and clear.  And as long as no
  one begins extending package Q.Classwide or any of the other original
  derivations, everything is nice and neat.

  However, as we begin doing more extensions, it will become more
  difficult to apply the kinds of predicitive metrics we might be
  able to apply to a non-extensible model.  Even coverage analyzers
  will take a little longer to produce the information we require.

  Oh, and yes, are there any coverage analyzers that will work on the
  extensible, dispatching model built around child packages?

  I did not say this was impossible.  I do think we can count on it being
  a tad more difficult.  This should not discourage us from using the Ada
  95 model.  It is certainly not as unruly as that found in some other
  languages.  But I do think it adds a whole new dimension to the
  practice of predictive metrics.

  Richard Riehle