Mail Archives: djgpp/1997/05/05/12:45:44
On Mon, 5 May 1997, Michael Mauch wrote:
> In the meantime I translated my 16 bit source code to work with DJGPP.
> It uses the Virtual Timer Device of Win3.1/Win95 if this is available,
> otherwise it calls the original uclock().
This might be a good addition to the library. Thanks.
> Although it seems to work, I'm
> not sure how accurate it is - as much as we can expect timing accuracy
> in Windows. I looked at the output of a test program (with different
> intervals, this time) using gnuplot, and it shows up that it is a lot
> slower than uclock(), and there are a lot of peaks (some of them up to
> 60000 tics, i.e. 50ms), but there a no negative values anymore.
I'm not sure I understand. Is that performance good enough to live up to
the docs of `uclock' when it is called from Windows?
> Another question is, if there is a wrap-around anywhere (there's none at
> midnight).
Can you leave it to run for a day and see if the Interrupt List is
right? I don't see any other way to be sure.
> And I don't know why the original uclock() source uses __bss_count (what
> is __bss_count?):
That is the DJGPP way to make sure any one-time initializations are done
even if the calling program has written its image from memory to disk and
you are invoking that image. In that case, the usual test of static
variables being zeroed doesn't work (since the data in .bss section gets
values before the image is written), so the function won't
re-initialize. The `__bss_count' variable is incremented unconditionally
by the startup code when the program starts, and can therefore be used as
an indicator that the program has been restarted.
If you are wondering why a program might need to do such weird things, it
is because sometimes programs need lengthy initializations which are pain
to do every time the program starts. In such cases, one solution is to
perform the initializations only once (when the program is built), then
dump its memory image to disk. You then install the dumped image,
thereby saving the initialization stage when using it. But some
initializations, such as reading environment variables, cannot be
recorded in the image, since the dumped program can run with a different
environment or on a different machine. So library functions need a way
to reinitialize unconditionally.
The only program known to me that needs this (and for which this feature
was introduced) is Emacs. The initialization it needs are loading all of
the Lisp packages that define basic Emacs commands.
- Raw text -