hi all,

Turns out i'd pulled the dumbest trick in the book and forgotten to do
a `make depend'.  The first kernel I put up hung early in boot.

However, I got some useful data: a 5000/240 and a 5000/133 show
approximately the same CPU rating.

>From that my conclusion is that the mips1 timing loop is dominated by
polling for the next clock interrupt.  I've tried sticking a couple of
`nop's into the loop, to see if that helps.

One more thing I didn't say is that this kernel includes code which
does DELAY(1000000), calling microtime() before and after, and then
recomputing the DELAY loop multiplier by 1000000 / usecs-delayed.

e.g, from dmesg on my machine at home:

   cpu0 at mainbus0: cpu0: MIPS R4000 CPU Rev. 3.0 with MIPS R4010 FPC Rev. 0.0
   cpu0: L1 cache: 8kb/16b Instruction, 8kb/16b Data, direct mapped
   cpu0: L2 cache: 1024kb/32b mixed, no snooping
   1sec DELAY() took 1.1002002 secs
   changing cpuspeed from 25 to 25
   new 1sec DELAY() took 1.1001960 secs

I've confirmed that works correctly on a couple of mips3 machines,
even when the intial value for cpuspeed is off by a facvtor of 3 or 4.

It hasnt been run on the mips1 models which lack a high-res counter--
on pmaxes, the 5000/1xx, the 3100, and the 2100. I'd appreciate
hearing how this works on those machines. (they have only 3906 usec
resolution, so it should be off by no worse than 2 parts in 256:)).

Also (assuming this all works), I'm not sure whether to put this into
sys/arch/mips or not.  The newsmips currently uses the same DELAY()
macro as the pmaxes; but do we want to embed this for all mips machines?

(My take is that if it works, and we can autocalibrate it, why not?)