Intel specific instruction set recognition.

[hutch--]

I have given up on trying to write code for AMD hardware as I have no way of testing it. The attached file is the final test piece for the original task of producing a library to test SSE up to the current SSE4.2. The code works on i7, Core series and PIV hardware and from the testing done by some of our members it appears to work on much older hardware back to the early Pentium series processors so the libraries do what they were originally intended to do.

If anyone is interested in writing AMD specific code to do the same task I would be happy to add it to the collection but I just don't have the hardware to design and test on.

[dedndave]

as i get time, i am working on a routine that just returns bits in EAX, Hutch - no strings
i think i have a feasible work-around for Cyrix and NexGen

in the low word of EAX (i.e. AX):

Code Select Expand


00 MMX
01 MMX+
02 SSE
03 SSE2
04 SSE3
05 SSSE3
06 SSE4a
07 SSE4.1 Intel
08 SSE4.1 AMD
09 SSE4.2
10 3DNow!
11 3DNow!+
12 RDTSC supported
13 486+
14 CPUID supported
15 OS supports SetProcessAffinityMask

each feature bit is set only if all processor cores in the system support that feature

the upper word will be used for basic ID of Core 0 - family/model/brand index/L2 cache/vendor ID number
i hafta cram stuff in there, so i haven't defined the bits yet

i had this partially written when i lost my other drive   :'(
thought i better re-do it while it is still somewhat fresh in my head

[hutch--]

Dave,

Stick it into a structure so its easier to use, no bit masking in the evaluation, just 0 or 1.

Pseudo code.

Code Select Expand


.if struct.sse == 1
  Show YES
.else
  Show NO
.endif


[dedndave]

no bit masking in the evaluation, just 0 or 1.

not sure i understand what you mean, Hutch
(i understand the structure part   :P )

oh - you mean they don't want to test bits to find if a feature is supported ?

[jj2007]

You could use RECORD/FIELD also...

[dedndave]

i think he wants it to be easy enough for a PB programmer   :P

[hutch--]

 :bg

No, as a matter of fact I mean write it as re-usable code that does not have to do the bit masking for each application that may need it. Passing a structure to the procedure that does the testing is fast easy and convenient. Using a structure has another advantage, you can add to the structure without breaking existing code. Add support for MMXXXXX and SSSSSSE 123456 is just an extra couple of structure members.

[Vortex]

Here is my log file :

Code Select Expand

Vendor String = GenuineIntel
CPU String    = Intel(R) Pentium(R) 4 CPU 3.20GHz

SSE4.2     NO
SSE4.1     NO
SSE3       YES
SSE2       YES
SSE        YES
MMX        YES


[dedndave]

well - i was trying to keep it simple, is all
if i go with a structure, i may as well provide the strings

[hutch--]

Dave,

Strings are fine for the vendor and processor ID but for instruction sets numeric options are a better bet and easier to use if an app needs to test if it can use 3DNow or sse4.1, they just have to test against a structure member.

[dedndave]

is it ok if it is a byte ?
or would you prefer dwords ?

[hutch--]

Dave, an architecture something like this to make it easy to track and easy for an end user.

Code Select Expand


    DAVE_CPU_INFO STRUCT
      SSE5  dd ?
      SSE4a dd ?
      SSE42 dd ?
      SSE41 dd ?
      etc etc ....
    DAVE_CPU_INFO ENDS

In caller

    LOCAL dci   :DAVE_CPU_INFO

    invoke DaveCpuInto,ADDR dci

    .if dci.SSE4a == 1
      print "SSE4a is supported",13,10
    .endif

    .if dci.MMXX == 1
      print "Extended MMX is supported",13,10
    .endif

  ; etc etc ....



DaveCpuInto proc pStruct:DWORD

    push esi

    mov esi, pStruct

  ; produce each result then write it to each required structure member

    .if eax == 1
      mov (DAVE_CPU_INFO PTR [esi]).SSE4a, 1
    .else
      mov (DAVE_CPU_INFO PTR [esi]).SSE4a, 0
    .endif

  ; etc etc ....

    pop esi
    ret

DaveCpuInto endp


[dedndave]

i can make a structure   :bg

here is what i am getting at
if we are going to have a dword value, we may as well put the string in there
if the first byte - or, for that matter the first 4 bytes, are 0 it means the feature is not supported
it won't take that much more room to make the following strings:

"MMX",0
"MMX+",0
"SSE",0
"SSE2",0
"SSE3",0
"SSSE3",0
"SSE4.1",0
"SSE4.2",0
"SSE4a",0
"3DNow!",0
"3DNow!+",0

in the structure definition, we can give them a dword size
if they want the string - they don't usually access it by bytes - they access it by address
they can grab the address of the dword to display the string
if they grab the dword, any non-zero value means the feature is supported
it doesn't take much more code to have
mov dword ptr SomeStructure.SomeValue,1
mov dword ptr SomeStructure.SomeValue,"SSE3"
(that isn't the exact code, but you get the point)

[hutch--]

You could do it that way but then the end user has to string match each result to determine what instruction set an app can use.

Code Select Expand


.if SSE3 == 1
  call SSEfunc
.else
  call IntegerAlternative
.endif


[dedndave]

oh - they can't test for "SSE3 not equal to 0"

or

Code Select Expand

.if SSE3 == 0
  call IntegerAlternative
.else
  call SSEfunc
.endif
we really need to help those PB&J guys   :bg
when they say "1's and 0's", they really mean it
i am glad this isn't 64-bit