Date:	Sat, 19 Jul 1997 08:32:20 -0700 (PDT)
Message-Id:	<199707191532.IAA22789@adit.ap.net>
Mime-Version:	1.0
To:	csantill AT lausd DOT k12 DOT ca DOT us
From:	Nate Eldredge <eldredge AT ap DOT net>
Subject:	Re: Standard tiiming func's & O3+ cause odd errors
Cc:	djgpp AT delorie DOT com

Is it possible that that piece of your code runs in less than a timer tick?
Although CLOCKS_PER_SEC claims to be about 1000000, in reality the 55 ms
timer ticks are just scaled to produce the clock() output, leading to big
jumps. So if your code executes in less than 55 ms, the difference between
clock() calls could be zero, leading to a divide-by-zero error. Adding
optimizations could be causing this by making your code faster. If this is
indeed the case, you can run the code several times inside the clock()s, or
check for the possibility that t[2] == t[1].

You wrote:
>Now that I got some working mode 13h code to hack
>(thanx alot to Sinan!), I decided to test how fast
>it was.  I've been using uclock & clock to do my
>timing procedures but I always seem to get a
>SIGFPE error(division by zero) at line 54:
>
>fps=7680/((t[2]-t[1])/UCLOCKS_PER_SEC)
>                or
>fps=7680/((t[2]-t[1])/CLOCKS_PER_SEC)
>
>This is odd because it does not occur when I compile
>w/O0 or O1.

Nate Eldredge
eldredge AT ap DOT net

- Raw text -