Re: delay until and GNAT - expand

[Robert Dewar <robert_dewar@my-dejanews.com>]

In article <rracine.15.000968A0@draper.com>,
  rracine@draper.com (Roger Racine) wrote:
> So why were these issues not debated when the Reference Manual
> was being  reviewed?  What type of metric were the writers
> thinking about?  Or did they  expect an answer like "between
> 350 and 3500 clock cycles, depending on your use of the
> processor"?
>
> Roger Racine
>

It is interesting to post the starting point of this thread:

    Does  someone  know  the  upper bound  on the lateness of
delay  until
    and delay relative for  Gnat  implement.  on  Win95 , WinNT
or  Linux.

Roger maintains that a good real time operating system can get
this figure
down to one microsecond. This clearly depends on what is meant
by "good"
ROS. If you mean one which you construct for the purposes of
Ada, I think
one microsecond is far too long (the RT exec I wrote for
Honeywell for
an 8080 would do full task switches in a few microsecondes, and
I think
machines are a *bit* faster now :-)

However, I suspect that virtually everyone is running GNAT on
systems that
are by Roger's definition, not good. In particular, the only
quantitative
input we have is for VxWorks on a 400MHz Pentium II, with a
special patch
from WRS to tune up context switching, and this figure is 22
microseconds
(it was 70 microseconds before the tuneup).

I prefer to deal with what I can actually see today, and what
people are
actually running, rather than an imagined ideal situation. If
Roger can make
this situation true, great.

One thing that has happened in the Ada world is that virtually
no one is
working on bare boards any more, everyone wants to run on top of
real
unixes (we know of serious RT development on top of Sparc
Solaris for
example), or real time executives like VxWorks. A lot of serious
realtime
work is also being done on NT.

As for what people had in mind in the RM metrics? First these
were the
product of a realtively small group of people, and I don't think
many
people paid much attention to them. Indeed all documentation
requirements
are a bit bogus in a formal standard for a language, since they
have to
do more with usability, and cannot for example be tested during
validation
in any meaningful way.

Historically, this concern came from a mindset of implementing
Ada on
a bare board with complete control over the Ada tasking
executive, as
was common in the Ada 83 world. There were even those who
insisted that
specific timing constraints be written into the requirements
(e.g.
RV shall take no more than XXX instructions/cycles etc) That
would
clearly be absurd in the context of the ISO standard, and the
metrics
are a kind of compromise position that also does not make a
whole lot
of sense.

At least, speaking as one of the reviewers, that is my view of
the
metrics requirements in the RM.

P.S. Someone should post a delay latency measuring program, it's
not that
hard to write, and then we can run it on multiple systems and
compilers.
Of course it does not give the metric, since this is not
measurable, but
it is still an interesting figure.

P.P.S. when I wrote earlier in the thread that Roger was "quite
wrong" in
suggesting the one microsecond figure, I was really thinking in
terms of
the original post quoted above, not his claim that he can
achieve this in
new software. I apologize for this confusion. In fact I think
that for a
purpose written Ada exec for a reasonable chip, one microsecond
is indeed
conservative.

P.P.P.S. I am not sure that Roger's measurements are meaningful
for NT.
I would not expect stepi to be able to step into ring 0 kernel
stuff
so easily, and I suspect that these results may be misleading.
Really
the only thing that is convincing is to run an Ada test program.


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---