OSDev.org

srg wrote: One thing I didn't understand from the BogoMips FAQ was the algorithm to actually calculate it. It points to the Linux Kernel code but I've always found the linux kernel code to be about as clear as mud.

#include <stdio.h>
#include <time.h>

static void delay(int loops)
{
  long i;
  for (i = loops; i >= 0 ; i--)
    ;
}

int main(void)
{
  unsigned long loops_per_sec = 1;
  unsigned long ticks;
  
  printf("Calibrating delay loop.. ");
  fflush(stdout);
  
  while ((loops_per_sec <<= 1)) {
    ticks = clock();
    delay(loops_per_sec);
    ticks = clock() - ticks;
    if (ticks >= CLOCKS_PER_SEC) {
      loops_per_sec = (loops_per_sec / ticks) * CLOCKS_PER_SEC;
      printf("ok - %lu.%02lu BogoMips\n",
         loops_per_sec/500000,
        (loops_per_sec/5000) % 100
        );
      return 0;
    }
  }
  printf("failed\n");
  return -1;
}

NAME
clock - Determine processor time

SYNOPSIS
#include <time.h>

clock_t clock(void);

DESCRIPTION
The clock() function returns an approximation of processor time used by
the program.

CONFORMING TO
ANSI C. POSIX requires that CLOCKS_PER_SEC equals 1000000 independent
of the actual resolution.

Solar wrote: Easy enough, I think.

Pype.Clicker wrote: The way "loops_per_second" is doubled at every attempt seems odd to me. Meditate on this, i will ...

Pype.Clicker wrote: The way "loops_per_second" is doubled at every attempt seems odd to me. Meditate on this, i will ...

Solar wrote: u try 8, 16, 32, 64 until you have a value of That way, a slow machine won't spend ages in the calibration loop.

Of course, in kernel space you'd have to worry about where to get clock() ticks and the CLOCKS_PER_SEC value. That's where you pick up the Intel manual and read about the CPU#s MSR time stamp counter and how to read it.

Following reset, the (time stamp) counter is incremented every processor clock cycle, even when the processor is halted by the HLT instruction or the external STPCLK# pin. However, the assertion of the external DPSLP# pin may cause the time-stamp counter to stop and Intel SpeedStep? technology transitions may cause the frequency at which the time-stamp counter increments to change in accordance with the processor's internal clock frequency.

Solar wrote: The clock() function needs some non-locking way to measure passing time. Dunno what's available or not on the 386.

srg wrote:

Solar wrote: The clock() function needs some non-locking way to measure passing time. Dunno what's available or not on the 386.

nothing on chip

nick8325 wrote:You can tell how many cycles each instruction will take to execute on 386, though - google for 386intel and look at the instruction reference. Perhaps you could run some long instruction lots of times and see how long it takes. That just leaves the 486...

get_old_CPU_speed:
     push ecx

     mov eax,IRQhandlerA
     call set_timer_IRQ_handler        ;Change IRQ handler

     jmp $                             ;Do nothing until first timer IRQ occurs

endTiming:
     mov eax,ecx
     pop ecx
     ret



     align 32                          ;Make sure it starts on it's own cache line

startTiming:
     clr ecx                           ;Clear counter and cause initial cache miss
.wait:
     times 66 shl eax,1                ;3 cycles (total of 198 cycles)
     inc ecx                           ;2 cycles on 386, 1 cycle on 486
     jmp .wait                         ;8 cycles on 386, 3 cycles on 486



IRQhandlerA:
     mov eax,IRQhandlerB
     call set_timer_IRQ_handler        ;Change IRQ handler

     mov al,0x20
     out 0x20,al
     add esp,12                        ;Clean stack (remove CS, EIP and EFLAGS)
     sti
     jmp startTiming



IRQhandlerB:
     mov eax,original_IRQhandler
     call set_timer_IRQ_handler        ;Restore original IRQ handler

     mov al,0x20
     out 0x20,al
     add esp,12                        ;Clean stack (remove CS, EIP and EFLAGS)
     sti
     jmp endTiming