comp.lang.ada
 help / color / mirror / Atom feed
From: "Samuel T. Harris" <u61783@gsde.hso.link.com>
Subject: Re: ADA task
Date: 1996/09/14
Date: 1996-09-14T00:00:00+00:00	[thread overview]
Message-ID: <323B1F23.2781@gsde.hso.link.com> (raw)
In-Reply-To: dewar.842718568@schonberg


Robert Dewar wrote:
> 
> Samuel Harris
> 
> "Unfortunately, Ada 83 semantics specify only that the delay
> will be at least as long as the delay. It can be more then
> the delay (possible much more). It depends on the fidelity
> of the runtime system, the desired frequency, and the load
> caused by other tasks.
> "
> 
> This is true from a formal point of view, but any decent Ada 83 compiler
> that has any pretense to being usable for real time or simulation
> purposes using tasking should provide an effective delay implementation
> corresponding to the Ada 95 semantics.
> 
> If your Ada 83 comnpiler has a junk implementation of delay, I would
> simply replace the compiler.

I'm not sure what is the point of contention.
I did not imply good nor bad delay implementations.
I did detail the factors relating to the true fidelity of the
delay implementation (whatever that may be) and formal or not,
these issues are a real concern.

Every compiler will have a fidelity of delay it can support.
On our SGI systems, both VADS and GNAT support a 0.01 second delay
fidelity. Delays command to be less than 0.01 seconds are actually
0.01 seconds. This is not acceptable to high fidelity harmonic
simulations involving a least common multiple rate of greater
than 100 hertz. If no compiler supports the required fidelity,
then replacing the compiler is not really a viable option.

Even the "best" delay implementation will only support a certain
fidelity and as long as one's requirements are within that fidelity,
then okay. The original sender did not specify the required fidelity
so I presented a couple of alternatives implementations which rely
on (presumably) higher accuracy hardware clock devices.

There is also the factor of "drift". Computed delays introduce drift
since the actual delay is not strictly tied to the commanded delay.
No matter how close it is, the current time is still required to
determine the appropriate delay interval to use to arrived at the
next target time hit. That's why the new Ada 95 construct delay until
is so much simpler. I don't need to know what _now_ is each time.
I just need the first _now_ and keep adding the total time interval
to it.

Though I've not tested the new Ada 95 contruction at length yet,
I expect that the use of delay until will be much less sensitive
to the fidelity of the run time system. The time when the delay until
is commanded vs the time the delay until is commanded to use
will need to be above a certain minimum interval to guarantee
good correlation (I suppose). I can tune the load of each processor
to maintain that minimum interval with greater control than I
can keep each iteration to within a specific time band (which
I have to do with simple delay statements).

-- 
Samuel T. Harris, Senior Engineer
Hughes Training, Inc. - Houston Operations
2224 Bay Area Blvd. Houston, TX 77058-2099
"If you can make it, We can fake it!"




  reply	other threads:[~1996-09-14  0:00 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-09-11  0:00 ADA task Roumen Roupski
1996-09-12  0:00 ` Philip Brashear
1996-09-13  0:00 ` Norman H. Cohen
1996-09-13  0:00   ` Samuel T. Harris
1996-09-14  0:00     ` Robert Dewar
1996-09-14  0:00       ` Samuel T. Harris [this message]
1996-09-15  0:00         ` David C. Hoos, Sr.
1996-09-16  0:00           ` Samuel T. Harris
1996-09-16  0:00     ` Norman H. Cohen
1996-09-14  0:00   ` Ken Garlington
1996-09-14  0:00   ` Roumen Roupski
1996-09-16  0:00     ` Norman H. Cohen
1996-09-16  0:00   ` Robert I. Eachus
  -- strict thread matches above, loose matches on Subject: below --
1996-09-17  0:00 Marin David Condic, 407.796.8997, M/S 731-93
1996-09-20  0:00 ` Robert A Duff
1996-09-17  0:00 Marin David Condic, 407.796.8997, M/S 731-93
1996-09-19  0:00 ` Norman H. Cohen
1996-09-20  0:00   ` Robert A Duff
1996-09-18  0:00 tmoran
replies disabled

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