CPU identification code

[clive]

I'd have to check the Prescott's I have, one supports 64-bit without HTT, and the other HTT but not 64-bit. I'm not aware of them misidentifying, but you can kill HTT in the BIOS.

The Dual PPro's I have need new power supplies, but I think I have another board that should come up. Certainly have some PII systems.

Also all the PPro's I've used have CMOV, but Intel sometimes implies they are optional and other times speaks as if they are always present on PPro and PII architectures.

The code does appear to correctly identify SSSE3 in the Atom, rather than having SSE4 which the other testbed claims, although Intel does claim SSSE4 on one of it's pages, whatever that is. http://ark.intel.com/Product.aspx?id=36331

[Magnum]

I got this for my P-3. I wish I had a P-6.

Pentium Pro family (P6)

Instructions: MMX, SSE1

[clive]

http://en.wikipedia.org/wiki/P6_%28microarchitecture%29

Family : 3=386, 4=486, 5=Pentium, 6=Pentium Pro

[Antariy]

I attach "debug" version for testing on FORTRANS CPU PIII. I make temporal "fix" - just checking for having SSE2 - if not - then CPU have not brand name string.

Steve (FORTRANS) test this please on your PIII. Test will print return from CPUID 80000000h - for clearness, what is up on you CPU.

Also I change printing for P6 - PII printed as PII, PIII - as PIII.



Alex

[Antariy]

Clive, I saw page about Atom N270, is says what this CPU don't support SSSE3, but SSSE4. How this possible? I use Intel's manual from 2008 year to get CPUID bits, and this must be right, but I not have info about checking for SSS4.
This is specific to Atom - need threat SSSE3 as SSSE4?



Alex

[FORTRANS]

Hi Alex,

   Here are the results, PIII Windows 2000.  You still
looking for a PII?

Regards,

Steve N.

Code Select Expand

03020101        Debug message: extended functions count return

Pentium III

Instructions: MMX, SSE1



793 - size of all code and data of AxCPUid filling and printing proc

Press any key to continue ...

[Antariy]

Rockoon, you have info which can be reliable used to checking for AMD's extensions?
Sorry, but I have small time for all...

If you don't have detailed info about checking for AMD's extensions, you can get me binary opcodes for specific instruction set?
If CPUID cannot say (or you don't have info) about some sets, this is possible make simple SEH frame, with using all these binary opcodes in ascending order. When #UD will be generated - we would know, what this is not supported :) If catch line where exception are raised - we can found last supported instruction set with easy.

Of course, this is bad method, but if info about sets is not clear or full - this is most reliable checking, I think.



Alex

[Antariy]

You still looking for a PII?

Hi, Steve!

Yes, in this version I add printing for PII also. Now printed not just "PPro family", but short description for each generation.
If you have other P6 generation - test on them please.

Behaviour of CPUID 80000000h on your PIII is strange - Intel not says about that, really :)
In code I check for zero return, or 80000000h (add eax,eax;jz @done), because this is must be right behaviour for not existing extended functions, as far as I know.
Magnum test on PIII also, and his PIII reports about it right in old version of code.
Something implementation specific gives these results maybe.

So, need to check for SSE2 existence - this is most good way :) This way I use in todays' code.



Alex

[Rockoon]

Rockoon, you have info which can be reliable used to checking for AMD's extensions?

I have collected the bits that I think matter to userland asm programmers (some of them are for future extensions!)

Code Select Expand


CPUID(EAX = 1)
  ECX
    Bit 29 - F16C
    Bit 28 - AVX
    Bit 25 - AES
    Bit 23 - POPCNT
    Bit 20 - SSE42
    Bit 19 - SSE41
    Bit 13 - CMPXCHG16B
    Bit 12 - FMA
    Bit 9  - SSSE3
    Bit 1  - PCLMULQDQ
    Bit 0  - SSE3
  EDX
    Bit 28 - HTT
    Bit 26 - SSE2
    Bit 25 - SSE
    Bit 24 - FXSAVE/FXRSTOR
    Bit 23 - MMX
    Bit 19 - CLFLUSH
    Bit 15 - CMOV
    Bit 8  - CMPXCHG8B
    Bit 4  - TSC
    Bit 0  - x87 FPU

CPUID(EAX = 80000001h)
  ECX
    Bit 16 - FMA4
    Bit 11 - XOP
    Bit 6  - SSE4A
    Bit 5  - LZCNT
  EDX
    Bit 31 - 3DNow
    Bit 30 - 3DNow+
    Bit 37 - RDTSCP
    Bit 22 - MMX+



3DNow+ and MMX+ are extensions to each set, respectively. The extended MMX instructions eventually were implemented by Intel in SSE.

[FORTRANS]

Hi,

   Results for PII and Windows 98.  Your DOS mode stub
seems to be inactive?  Anyway it ran in a window.

Regards,

Steve N.

Code Select Expand

03020101        Debug message: extended functions count return

Pentium II

Instructions: MMX



793 - size of all code and data of AxCPUid filling and printing proc

Press any key to continue ...


[Antariy]

I have collected the bits that I think matter to userland asm programmers (some of them are for future extensions!)

Thanks, Rockoon!

"some of them are for future extensions" - this is meant what these bits can be undefined on early AMD architectures?



Alex

[Antariy]

   Results for PII and Windows 98.  Your DOS mode stub
seems to be inactive?  Anyway it ran in a window.

Thanks, Steve!
Yes, I used not working stub with size of 64 bytes. With absence of "Rich garbage" this is make PE header started at 40h offset.
Under DOS running app is not possible - "too big to fit in memory". This is satisfactory for 32bit app under DOS :)

Version posted today - almost yesterdays version, without "Debug message" only.
When I find time, I try implement info which Rockoon gives to me.



Alex

[Rockoon]

I have collected the bits that I think matter to userland asm programmers (some of them are for future extensions!)

Thanks, Rockoon!

"some of them are for future extensions" - this is meant what these bits can be undefined on early AMD architectures?



Alex

I believe that by Intel/AMD definition, all "undefined" and "reserved" bits must be 0 on return from CPUID. That is, they never report true until the usage is defined. The instruction would be almost pointless otherwise.

[dedndave]

CPUID leaf 80000000h returns the largest supported extended leaf.
To ID the Pentium 1/Pro/2/3's, use the Processor Signature from leaf 00000001h EAX register.
The Intel document 241618.PDF has quite a few errors in the Signature table.
I have corrected most, if not all, of these errors in the Signature table pic...

http://www.4shared.com/file/WHXNrzwq/Signature.html

If you read the footnotes, it points you to the individual update PDF's for the Pentium 1/Pro/2/3 Family/Models.
This is primarily where I got the correct info, along with sites like cpuworld, etc, that have partial CPUID dumps.

You may also want the Brand Index and L2 Cache type to identify specific chips.
The Family and Model values are combined in the low-order byte of the 00000001h leaf EAX Signature (AL).
For later 486's that support CPUID, the Family bits are 0100.
For the Pentium I's, the Family bits are 0101.
All the Pentium Pro/2/3's are in Family 0110 - use the low 4 bits (Model) to sort them out.

Update: As I recall, all Intel CPU's prior to family 6, model 0Bh do not support Brand String.
All Intel CPU's from family 6, model 0Bh and up do support Brand String.
I think nearly all AMD chips do support Brand String.

The AMD CPUID document is...

http://support.amd.com/us/Processor_TechDocs/25481.pdf

[Antariy]

I believe that by Intel/AMD definition, all "undefined" and "reserved" bits must be 0 on return from CPUID. That is, they never report true until the usage is defined. The instruction would be almost pointless otherwise.

Yes, this is *must* be right behaviour. But, for example for Steve's PIII, extended function 80000000h returns 03020101h, not zero as must. This is strange and funny. Magnum's PIII return zero as needed, because on his machine old code identify his CPU right.



Alex