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.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,8c564a80b820db35
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.68.129.169 with SMTP id nx9mr28872pbb.2.1331065388466;
        Tue, 06 Mar 2012 12:23:08 -0800 (PST)
Path: 
 h9ni47073pbe.0!nntp.google.com!news2.google.com!goblin3!goblin.stu.neva.ru!gegeweb.org!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: Any leap year issues caused by Ada yesterday?
Date: Tue, 06 Mar 2012 20:22:39 +0000
Organization: A noiseless patient Spider
Message-ID: <m2sjhlh434.fsf@pushface.org>
References: <4f4f746a$0$6565$9b4e6d93@newsspool3.arcor-online.net>
	<abdf6306-50b4-43ed-9e18-3c57c1e97160@9g2000vbq.googlegroups.com>
	<20608866.730.1330963171058.JavaMail.geo-discussion-forums@ynbq18>
	<1t8v4akrmapkl.1xwfi9yxtw2ji$.dlg@40tude.net>
	<m2eht6j3xl.fsf@pushface.org>
	<msh09luylmxz$.qdnnl7pz5j14.dlg@40tude.net>
	<m2aa3uix7a.fsf@pushface.org>
	<18ghv3yeh1a1k$.1bjwdaps59rt3$.dlg@40tude.net>
	<m262eihyq0.fsf@pushface.org>
	<d37aucb0avr1$.ihxbw6kqhx1e$.dlg@40tude.net>
	<m21up5isno.fsf@pushface.org>
	<z3eblji2o1wx.1ts993li80h61$.dlg@40tude.net>
	<m2wr6xhaqf.fsf@pushface.org>
	<f7swwaoskj5m$.1aqwzadr8kaul$.dlg@40tude.net>
Mime-Version: 1.0
Injection-Info: mx04.eternal-september.org;
 posting-host="dFCm8HWntFqmDIilBLqEJQ";
	logging-data="20635"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1/b8dOSG2pB7Qhw55fNib+v2ajQQYJVe5s="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (darwin)
Cancel-Lock: sha1:0Q2yvbDDre23J43SCGHuh9GOJ+A=
	sha1:XP6eI0zdaEdypOk8QZ6vleY1jgg=
Content-Type: text/plain; charset=us-ascii
Date: 2012-03-06T20:22:39+00:00
List-Id: <comp.lang.ada>

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Tue, 06 Mar 2012 17:59:04 +0000, Simon Wright wrote:
>
>> The timebase ran off the same crystal as the decrementer, so all were
>> internally sync'd. Internally, our synchronised time was
>> (Ada.Calendar.Clock (at last clock interrupt, of course) + high-res time
>> since last clock interrupt).
>
> You could improve that a bit by putting Ada.Calendar.Clock into a loop.
> When it returns a different value, you exit the loop and take that value
> for the time base.

Ada.Calendar.Clock was basically the POSIX gettimeofday() (?) from
VxWorks; which was (epoch + ticks/clockrate). So it was updated at clock
interrupt.

> If the quartz is same you need not to synchronize it anymore. Since the
> multiplier is known you simply add the RTC minus its value at the base
> multiplied by the factor and converted to Duration (or Time_Span) to the
> base and use that instead of the original Ada's Clock.

Didn't want to mess with the RTS use of Ada.Calendar.Time for delays. No
point in using Ada.Real_Time.Time because (then) it was the same as
Ada.Calendar.Time. So we had AC.Time (for internal use only),
<Project>.Calendar.Time for both internal & external use (but not, of
course, for delays).

> Did you check the kernel settings? It has a variable that sets the time
> source to the RTC. This might work on your PPC's BSP. The effect is that
> the system clock is changed each time when queried rather than upon timer
> interrupts.

Don't remember that one.