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,1356f4179c1e4ef4 X-Google-Attributes: gid103376,public From: "Samuel T. Harris" Subject: Re: ADA task Date: 1996/09/14 Message-ID: <323B1F23.2781@gsde.hso.link.com>#1/1 X-Deja-AN: 180643506 references: <5174qu$o1p@nr1.ottawa.istar.net> <51cjp0$q7k@watnews1.watson.ibm.com> <323A1FF2.2781@gsde.hso.link.com> content-type: text/plain; charset=us-ascii organization: Hughes Training Inc. - Houston Operations mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 3.0 (X11; I; IRIX 5.3 IP19) Date: 1996-09-14T00:00:00+00:00 List-Id: 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!"