Re: [Geekos-devel] Re: IDE driver details

[David H. <da...@cs...>]

On Tue, Jan 29, 2002 at 07:02:24PM -0600, 'Parc' wrote:
> On Tue, Jan 29, 2002 at 06:19:48PM -0500, David Hovemeyer wrote:
> [snip]
> > 
> > Is the idea that you'd program a one-shot timer, and wait for
> > it to go off?  Would the resolution be sufficient?
> > 
> Yes and no.  I'm still researching a bit, but I'll have a design
> made up pretty soon, and should have an implementation pretty quickly.
> The basic is that I'm going to fire off the RTC with a 2x divider.  That
> gives me a 8MHz clock.  When you nanosleep, I'll fire it up, and turn it
> off when the timer is done.  It looks stupid, though, so I'm still thinking
> about it.

Sounds good.

[snip]
> > I looked at the Linux BogoMIPS code, and it's pretty hairy.
> > So, I hacked something similar into timer.c; basically, it runs
> > a similar loop, and determines how many iterations occur in one
> > timer tick.  The patch is attached to this email.  (I'm going to
> > commit it, so you can also just cvs update.)
> I really don't like that.  The compiler can optimize that completely out
> if it feels like it.  Also, CPU caching changes how it behaves.  If
> something invalidates your cache while you're spinning, the timing won't
> be accurate.

I rewrote the loop in inline volatile asm, so it won't get
optimized out.  (Will commit this soon.)

The code does rely a bit too intimately on gcc to not mess it up.
The main dangers are (1) that the stack pointer might change
between when the eip is saved and reset by the interrupt handler
(which would cause massive lossage), and (2) that the "count"
variable might not get allocated in a register, or might occupy
different registers at different times, which would result in
an invalid timing result.

Case (1) is not likely to happen, especially if we compile with
optimization.  Case (2) is a bit more likely, but I think making
the counter a "register" variable solves this case.
Anyway, the code works.

Regarding a cache invalidation (due to an interrupt occurring?)
messing up the timing, yes, this could certainly happen.  However,
I think that's OK.  The semantics of this sort of delay would be
"wait for *at least* the specified amount of time".  If it waits a
bit longer, no big deal.

> BogoMIPs are just bogus.  There are variables that I don't think are
> good to rely on.

Here's my take on using a spin loop to delay.  This is for really
short delays (400 ns is less than a millionth of a second).
It's too short a period to schedule another thread, so therefore
the processor may as well be completely idle.

>  Then again, I don't do OS coding for a living, so
> I could be wrong... :)

I would also like to invoke this disclaimer :-)

-Dave