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=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8c3f76cf9b2829c4 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-01-31 11:17:49 PST Path: supernews.google.com!sn-xit-02!supernews.com!nntp-relay.ihug.net!ihug.co.nz!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed1.earthlink.net!newsfeed2.earthlink.net!newsfeed.earthlink.net!news.mindspring.net!not-for-mail From: Marin David Condic Newsgroups: comp.lang.ada Subject: Re: Duration vs. Ada.Real_Time Date: Wed, 31 Jan 2001 14:16:39 -0500 Organization: MindSpring Enterprises Message-ID: <3A786497.1C791722@acm.org> References: <980495512.529981@edh3> <3A71814B.7E8CCF60@acm.org> <94s5bl$r1r$1@nnrp1.deja.com> <3A71E4F6.6D7015AD@acm.org> <94vo82$kst$1@nnrp1.deja.com> <959d0c$gsg$1@nnrp1.deja.com> NNTP-Posting-Host: d1.56.b1.5c Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 31 Jan 2001 19:15:57 GMT X-Mailer: Mozilla 4.07 [en] (WinNT; I) Xref: supernews.google.com comp.lang.ada:4775 Date: 2001-01-31T19:15:57+00:00 List-Id: You are right. It is "not that simple" - certainly for a number of possible targets. I think my only point here was that there are some hardware configurations where you *do* have a time source that *could* be reflected by Duration and when that is the case, that's probably what you want to do. In your example you have three possible time sources. Which would you pick for dealing with Duration? Which would you pick for Ada.Real_Time.Time_Span? Maybe for this particular hardware configuration you make Duration have some arbitrarily large precision and move on. Maybe where you have a gate array or some on-board register or some similar configuration wherein you can interrogate the time source & get a scaled integer with an LSB of - say - 1uSec, then Duration ought to reflect this. I'm not saying all Ada compilers everywhere should do this for every target - just where it makes some sense because of what the hardware or OS provides you. It might be possible to make it user configurable (select time source and select precision, then rebuild so the compiler gives you what you want.) For embedded and realtime applications, I think this is a useful feature. MDC Ted Dennison wrote: > In article , > Stephen Leake wrote: > > > Perhaps it would be more appropriate for Marin to request that type > > Ada.Real_Time.Time_Span (LRM appendix D) match the hardware clock; > > that is more clearly intended to be a "hard real-time" clock type. > > OK. I've tried to just say "its not that simple". Since no one seems to > be accepting that, let's look at this suggestion in detail. Let's > postulate a PC system, since that's the most common one in use. > > The PC system has 3 built-in timing methods. The first is the > "Real-Time" clock, which is usually used to drive OS scheduling > operations. This is essentially the 8253 timer chip, which divides > 4.77272MHz signals from the processor (I'm not sure if this is standard, > or varies depending on the processor or bus speed. I'm also not sure if > its exact, or an approxmiation) into some convienent number of RTC > interrupts (like by 65536 to produce interrupts at 18.20648Hz). > However, it is possible for software to change this amount. Thus, if an > Ada compiler were to use "the units of the clock" for this clock, it > would have to use either some huge number in units of 4.77272 x 10^^-6 > (or whatever the particular system uses for its base), or it would have > to somehow dynamcily pick the units that the RTC happens to be spewing > out at the moment (and be ready to change if software changes it). > However, the OS most likely uses its own approximation for these units, > so the compiler would have to approxmiate whenever passing control to > the OS for actual scheduling. > > There is also a "time of day" clock that just keeps a counter in memory. > For most Ada compilers this clock will only be accessed through OS > system calls. Whatever units the OS uses would be OK here. > > There is also a high-frequency timer. This also just keeps a counter in > memory. However in this case it is the CPU doing it, and the counter > increments by one each time the CPU cycles. Thus its rate is dependent > on the clock rate of the CPU. It is possible to set up interrupts when > the counter reaches a (software-set) value. Thus this could be used, but > the Ada compiler would then have to pick units that match the processor > clock speed (which would probably not match any of the above). > > Short answer: its not that simple. > > -- > T.E.D. > > http://www.telepath.com/~dennison/Ted/TED.html > > Sent via Deja.com > http://www.deja.com/ -- ====================================================================== Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/ Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m Visit my web site at: http://www.mcondic.com/ "I'd trade it all for just a little more" -- Charles Montgomery Burns, [4F10] ======================================================================