This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: testsuite run-time test for sse2 support

Uros Bizjak wrote:
Joel Sherrill wrote:

 I hacked on that test program to get the attached
 program.  I ran it multiple times on qemu.

 ext=0x0 sig=0x756e6547
 0x781abfd YES on SSE2

I am now printing the return value from __get_cpuid_max()

ext=0x0 sig=0x756e6547 returned=0x2 0x781abfd YES on SSE2

Isn't the "sig" supposed to be >= 0x80000000?

No, it says "uneG" in Intel speak, as in "_Genu_ine Intel"

I ran the same program natively and got this:

 ext=0x0 sig=0x756e6547
 0xbfebfbff YES on SSE2

 I wonder if qemu is just reporting things wrong. :(
 I searched the qemu manual and googled some but
 didn't see anything that jumped out.

 Does this look like qemu reporting a bogus cpuid or
 gcc not parsing it correctly?

This all depends on the return value of __get_cpuid_max(). It returns
max value of base cpuid level (5 in my case), and shoould return 0 if
cpuid is not supported. This follows the procedure outlined in,
section 2: "Detecting the CPUID Instruction".

I added a print before the return on !__get_cpuid and it is returning
non zero.

So, this is qemu bug. It advertises CPUID support with %eax=2, and when
queried with cpuid, it returns SSE2 support. Either SSE2 should be fully
fixed in quemu, or it should stop advertising SSE2 (and other levels)
This is with the Fedora 8 qemu 0.90 RPM.  There was a 0.91
release in January and the ChangeLog mentions a new cpu model
command line option.  It looks like it might be better although
another command line I was using broke. <sigh>

Just to be sure this looks OK in qemu 0.9.1, here is the output
of the test program with the supported cpu models:

-cpu 486 results in

   ext=0x0 sig=0x756e6547 returned=0x0
   __get_cpuid returned 0

-cpu pentium results in
   ext=0x0 sig=0x756e6547 returned=0x1
   0x8001bf NO on SSE2

-cpu pentium2 results in
   ext=0x0 sig=0x756e6547 returned=0x2
   0x183f9ff NO on SSE2

-cpu pentium3 results in
   ext=0x0 sig=0x756e6547 returned=0x2
   0x383f9ff NO on SSE2

And this one just to keep things weird. Does it make sense?

-cpu qemu32 results in
   ext=0x0 sig=0x756e6547 returned=0x2
   0x781abfd YES on SSE2

I think it looks like I need to start using qemu 0.9.1 and add the -cpu 486 option.
It is true, that this is not the most maintained code on the planet,
so some bitrot is possible. The return value of __get_cpuid_max() on
your target will tell...

The call to __get_cpuid is checking against level 1 and this is a level 2.

This is cpuid level, not SSE level. We want cpuid information indexed with %eax=1.


Joel Sherrill, Ph.D.             Director of Research & Development        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available             (256) 722-9985

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]