<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 19, 2019, 3:33 PM Olaf van der Spek <<a href="mailto:ml@vdspek.org">ml@vdspek.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, May 19, 2019 at 2:31 PM tedheadster <<a href="mailto:tedheadster@gmail.com" target="_blank" rel="noreferrer">tedheadster@gmail.com</a>> wrote:<br>
><br>
> On Sun, May 19, 2019 at 7:31 AM Olaf van der Spek <<a href="mailto:ml@vdspek.org" target="_blank" rel="noreferrer">ml@vdspek.org</a>> wrote:<br>
> ><br>
> > What's eax after cpuid function 0?<br>
><br>
> After calling cpuid function 0x0, %eax returns the expected 0x1.<br>
><br>
> Here is the output of 'cpuid -r'.<br>
><br>
> # cpuid -r<br>
> CPU 0:<br>
>    0x00000000 0x00: eax=0x00000001 ebx=0x746e6543 ecx=0x736c7561 edx=0x48727561<br>
>    0x00000001 0x00: eax=0x00000585 ebx=0x746e6543 ecx=0x00000000 edx=0x008001b5<br>
<br>
ecx does contain 0 doesn't it? Or is this the wrong line?<br>
<br>Olaf<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I was fooled by that too. The /usr/bin/cpuid program is not the same as the gcc cpuid.h calls. I inserted debugging code and found that the %ecx register still had its part of the vendor string 'auls' in it (from 'CentaurHauls') from the earlier call to cpuid() with eax = 0.</div><div dir="auto"><br></div><div dir="auto">I posted a patch to the gcc-patches mailing list.</div><div dir="auto"><br></div><div dir="auto">- Matthew</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>