Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ucsfcca.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!ucbvax!ucsfcgl!ucsfcca!dick
From: dick@ucsfcca.UUCP (Dick Karpinski)
Newsgroups: net.arch,net.micro.mac,net.micro.68k
Subject: Re: timing loops
Message-ID: <443@ucsfcca.UUCP>
Date: Tue, 25-Feb-86 21:13:38 EST
Article-I.D.: ucsfcca.443
Posted: Tue Feb 25 21:13:38 1986
Date-Received: Fri, 28-Feb-86 21:47:51 EST
References: <156@motatl.UUCP> <530@hoptoad.uucp> <6780@boring.UUCP> <9645@amdcad.UUCP> <6790@boring.UUCP>
Reply-To: dick@ucsfcca.UUCP (Dick Karpinski)
Organization: UCSF Computer Center
Lines: 23
Xref: watmath net.arch:2629 net.micro.mac:4865 net.micro.68k:1520
Summary: Trim timing at run time

In article <6790@boring.UUCP> jack@mcvax.UUCP (Jack Jansen) writes:
>
>There is no way you'll write a device driver that is guaranteed
>to work with any C compiler, if you have to take care of timing
>considerations (unless you're willing to pay the penalty of using
>a *real* timer, of course).

I thought someone suggested a solution:  Build a timing loop, but
set its constant (how many cycles) using some other, possibly low
precision, timer to see how fast the loop is _today_ with this
compiler/clock/cpu-chip/whatever.  I _think_ that one can usually
count on those things remaining constant _during_ this run of the
program, i.e. between reboots of the OS.  I have heard of systems
which change their cpu clock on the fly, but you probably know
that when you write the device driver.  Is that enough?

Dick
-- 

Dick Karpinski    Manager of Unix Services, UCSF Computer Center
UUCP: ...!ucbvax!ucsfcgl!cca.ucsf!dick   (415) 476-4529 (12-7)
BITNET: dick@ucsfcca   Compuserve: 70215,1277  Telemail: RKarpinski
USPS: U-76 UCSF, San Francisco, CA 94143