Re: testsuite run-time test for sse2 support

[Joel Sherrill <joel dot sherrill at oarcorp dot com>]

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
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available             (256) 722-9985