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
http://download.intel.com/design/processor/applnots/24161832.pdf,
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)
support.
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.
Uros.
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
