Date: Mon, 5 May 1997 19:15:53 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Michael Mauch <mauch AT uni-duisburg DOT de>
cc: djgpp AT delorie DOT com
Subject: Re: testing uclock()
In-Reply-To: <336ea503.189123@news.uni-duisburg.de>
Message-ID: <Pine.SUN.3.91.970505190025.12253A-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


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.