Re: Duration vs. Ada.Real_Time

[Marin David Condic <mcondic.auntie.spam@acm.org>]

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 <uk87d9kjh.fsf@gsfc.nasa.gov>,
>   Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> 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]
======================================================================