News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

How do I read the CPU "signature"?

Started by Umesh T, April 22, 2011, 12:20:37 AM

Previous topic - Next topic

Umesh T

I have a vintage 486 running MS DOS 6.22

Is there some sort of a CPU "signature" stored in memory that tells me what the speed of the CPU is?

The bootup wouldn't tell me (no matter how much I tinkered with the ROM BIOS) nor would the subsequent screen that tells me it's a 486DX with 1.44"FDD and 8MB RAM etc.

dedndave

only later 486's support CPUID
the signature appears in the EDX register at reset, and BIOS presumably stores it someplace   :P

because you are running DOS, you might look at the segment starting at 40:0000 and see if it's there
otherwise, it may be stored in the RTC memory - i don't remember

even so, you are not likely to get CPU frequency info
a while back, Edgar and i wrote a CPU frequency program, but it was 32-bit code

Umesh T

Thanks, dedndave.
I'll try that this evening, when I get home.

dedndave

you might be able to measure it   :P

MichaelW

To reasonably measure the clock speed the processor needs to have a Time Stamp Counter, a feature which first appeared with the Intel Pentium. If you know that it is an Intel 486-DX, given the published per-instruction clock counts you might be able to estimate the clock speed by timing a series of instructions. Per the Intel Programmer's Reference Manual for the 486, the clock count calculations are based on the following assumptions:

Data and instructions accesses hit in the cache.

The target of a jump instruction is in the cache.

No invalidate cycles contend with the instruction for the use of the cache.

Page translation hits in the TLB.

Memory operands are aligned.

Effective address calculations use one base register and no index register, and the base register is not the destination register of the preceding instruction.

Displacement and immediate are not used together.

No exceptions are detected during execution.

There are no write-buffer delays.

So perhaps timing a loop something like this would work:

    mov ecx, 1000000
    align 2
  @@:
    REPEAT 96
        nop   ; 1 clock
    ENDM
    dec ecx   ; 1 clock
    jnz @B    ; 3 clocks, branch taken
              ; 1 clock, not taken


eschew obfuscation

clive

I used to time empty loops, against those with different instructions with known cycle counts. I'd use the 1.19 MHz timer on the 8253 gated across the looped code, with a loop count adjusted to try and maximize the use of the 16-bit counter. ie each tick being ~838ns, the maximum time being ~54.96ms.

This method is quite viable on all PC's from 4.77 MHz 8088's thru 3.0 GHz Penitum 4's running DOS/native.
It could be a random act of randomness. Those happen a lot as well.

dedndave

long ago, i wrote some code that worked the other way
it was written as an interrupt handler
one tick would start the loop
the loop code waited for the next tick
when you were done, it told you how many times it passed through the loop
it worked quite well, +/- 1 or 2 % as i recall

MichaelW

Quote from: clive on April 22, 2011, 11:57:57 AM
This method is quite viable on all PC's from 4.77 MHz 8088's thru 3.0 GHz Penitum 4's running DOS/native.

Except on the later, more complex processors the cycle count for a given instruction depends on the surrounding instructions, so it's not possible to predict with any accuracy what the cycle count for a section of code will be. For example, the loop code I posted should execute in 100,000,000 cycles on a 486, but even on and 11-year old P3 it executes in something like 50,000,000 cycles.
eschew obfuscation