Mail Archives: djgpp-workers/2003/05/04/14:10:17
Hello.
Gisle Vanem wrote:
>
> "Richard Dawe" <rich AT phekda DOT freeserve DOT co DOT uk> said:
>
> > + /* What we need is instruction family info in 8-11 bits */
> > + family = (cpuid_info & 0x780) >> 8;
> > + switch (family)
>
> I dont' get this. Isn't this extracting bits 7-10 (assuming we call the
> LSB bit 0).
No, because the rotate eliminates bits 0-7, leaving us with bits 8-10 in
family at bit positions 0-2.
The bitwise AND eliminates bit 11. This is the extended family bit.
Actually, the above comment & code are bit strange. I did not change them,
when I added the Athlon support. I modified it to store the family in a
variable, rather than just switching on the value.
Perhaps the comment and code should be more like this:
/* What we need is instruction family info in 8-11 bits.
* Ignore the extended family bit. */
family = (cpuid_info & 0x700) >> 8;
...
> > + {
> > + case 0x7: strcpy(u->machine, "i786"); break;
> > + case 0x6: strcpy(u->machine, "i686"); break;
> > + case 0x5: strcpy(u->machine, "i586"); break;
> > + default:
> > + case 0x4: strcpy(u->machine, "i486"); break;
> > + }
>
> > + if ((family == 0x6) && (strcmp(vendor, "AuthenticAMD") == 0))
> > + strcpy(u->machine, "athlon");
>
> Wouldn't this set "athlon" for a "duron" AMD K7 processor too?
> Check bit 7..4 to be sure.
"duron" does not seem to be in list of "machine hardware types" understood by
config.sub. (config.sub constructs triplets like i686-pc-msdosdjgpp.) Perhaps
the chose the name "athlon" for the K7-family, before the Duron was released?
Bye, Rich =]
--
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]
- Raw text -