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.7 required=5.0 tests=BAYES_00,MSGID_RANDY
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,f8311a3a7edd715
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2000-12-12 16:00:10 PST
Path: 
 supernews.google.com!sn-xit-02!supernews.com!newsfeed.mesh.ad.jp!newsfeed.direct.ca!look.ca!newsfeed.mathworks.com!news.maxwell.syr.edu!nntp2.deja.com!nnrp1.deja.com!not-for-mail
From: Ted Dennison <dennison@telepath.com>
Newsgroups: comp.lang.ada
Subject: Re: Using "delay until" in real-time
Date: Tue, 12 Dec 2000 23:49:25 GMT
Organization: Deja.com
Message-ID: <916di4$bl8$1@nnrp1.deja.com>
References: <915jl7$jt5$1@nnrp1.deja.com> <915p5n$p2j$1@nnrp1.deja.com>
 <915vv7$vfo$1@nnrp1.deja.com> <916aqq$9a7$1@nnrp1.deja.com>
NNTP-Posting-Host: 204.48.27.130
X-Article-Creation-Date: Tue Dec 12 23:49:25 2000 GMT
X-Http-User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US;
 m18) Gecko/20001207
X-Http-Proxy: 1.0 x61.deja.com:80 (Squid/1.1.22) for client 204.48.27.130
X-MyDeja-Info: XMYDJUIDtedennison
Xref: supernews.google.com comp.lang.ada:3026
Date: 2000-12-12T23:49:25+00:00
List-Id: <comp.lang.ada>

In article <916aqq$9a7$1@nnrp1.deja.com>,
  Mike Silva <mjsilva@my-deja.com> wrote:

> Yep.  You could, e.g. add 1.0 to Start_time and zero Iteration_count
> every 60 iterations.
>

Ahhh. That's essentially what I was talking about doing.


> Still, I think it's better to try and represent your iteration in
> units of Ada.Real_Time.Tick.  Then you are never dividing, only adding
> a scalar.  If Ada.Real_Time.Tick can exactly represent your system
> tick of 1/240 sec. then you should never have an error.  Then the
> question becomes whether Tick is an exact representation of the system
> tick time(seems like it would have to be!).

I don't know about that. The system call on this OS to set the clock
rate takes in units of iterations per second. If that is the actual
units that the real-time clock hardware uses, then there's no possible
way for something expressed in units of seconds (like
Ada.Real_Time.Tick) to represent the *exact* same amount of time.

However, its quite possible that the real-time clock hardware on my
platform (PC) uses something like nannoseconds, and the OS call just
approximates that. In that case it indeed ought to be possible for
Ada.Real_Time.Tick to be an exact match for what the hardware clock
uses. However, since this compiler works with any PC-based version of
this OS, it could be that there was no good way of knowing what the
real-time clock's exact internal representation of time would be, so
they made Ada.Real_Time.Tick an approximation anyway. I'll have to look
into this issue...

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/