Mail Archives: djgpp/2001/07/13/13:26:47
> From: invalid AT invalid DOT fi (Ilari Liusvaara)
> Newsgroups: comp.os.msdos.djgpp
> Date: Thu, 12 Jul 2001 14:55:16 GMT
>
> >From DJGPP Libc manual, function uclock():
>
> >You cannot time across two midnights with this implementation, giving a
> >maximum useful period of 48 hours and an effective limit of 24 hours.
>
> Is this limitation (almost) impossible to work around, it is already
> lifted in 2.04, it is in 'volunteers wanted'-stage or is the manual
> wrong (misleading)?
The problem is that `uclock' returns a value of the type uclock_t,
which is defined as long long. That's a 64-bit quantity, and since
`uclock's resolution is 840 nanoseconds, the 64-bit type overflows in
about 48 hours.
> I can't correlate what I see in code with manual description. If I
> read the source correctly, then if uclock() is called often enough
> (i.e. always two calls in 24hour sliding frame when the count is
> running), uclock() has practically no limitations of perioid.
I don't understand this. `uclock' returns the number of ticks since
the first call. That number always grows, until it eventually
overflows a 64-bit integer. It doesn't matter whether you call
`uclock' a lot or just one more time, what is reported is a difference
since the first call.
> I think that if timer routine (DJGPP installs it's own, right?)
No, `uclock' does not cause a timer interrupt to be installed. The
high resolution count is produced by combining the BIOS counter and
the timer chip counter.
- Raw text -