Bill said:
I read an interesting post on this which said that the logic is this: if
the CPU is Intel, the flags are checked, because the meaning of each bit
is known. If not, the meaning of some bits as used by other vendors is
not identical to Intel usage. Therefore, Intel chose to not use any
vector stuff beyond mmx (or sse) rather than try to handle other
vendor's use. Clearly you can call this an excuse, and Intel probably
could have checked for at least some of the other vendors, assuming that
within a vendor the bits are stable.
Yes, I can see them using that excuse too. The major performance
enhancing features at question here, such as the SSE instructions are
not in conflict.
Anyways, this is not just a matter for the FTC to take up, this is also
a part of Intel & AMD's private settlement: Intel has agreed to give up
this practice _from now on_. The FTC however is looking at it from a
consumer point of view, and it feels it has the right to ask Intel to
compensate customers who bought Intel's compilers without knowing about
this in the past.
I know there is/was one CPU vendor who used the bits Intel classified as
either "unused" or "RFU" to mean something, but I don't remember what.
There was code in some program I used which checked that. For modern
32/64 bit CPUs I doubt that's an issue, but I don't really know that
everyone uses bits the way Intel does.
It's certainly possible, but AMD used to use flags way outside of
Intel's flags functions. For example, for Intel-style flags you might
have had to put $1000 into a register, and for AMD-style flags you would
have needed to put $8000 into the same register. When checking for Intel
features on AMD processors, you simply used the Intel values and you got
back the Intel results.
As it turns out, now that AMD is responsible for the 64-bit x86
instructions, Intel now supports the AMD-style flags too. That's because
a lot of the 64-bit features come from the AMD flags.
Vendors in Pentium days (from memory), AMD, Cyrix, Transmeta, SiS, and
at least one other. Hope someone remembers this stuff more clearly.
Those were a bygone era, even before the CPUID was available. In those
days, you had to use indirect method to figure out which processor you
were running on, even within the Intel stable. You'd use things like
self-modifying code to measure the size of instruction prefetch queues
which might have been different between processor families, etc. I
remember writing such routines in assembly myself. Once the CPUID
instruction was introduced this all went away.
Cyrix made a Pentium-class processor, which didn't support the Pentium
instruction set instructions. So for all intents and purposes, the Cyrix
looked just like a really fast 486.
In any case, if that claim is true, it's still a very dubious reason to
avoid a more thorough check.
FTC is talking about making Intel license x86 to anybody who wants to
pay for it. I am figuring that this is the start of a "de jure" rather
than a "de facto" standards-based x86 instruction set. AMD will have to
throw in the x64 instructions too.
So we might actually see x86 processors from Nvidia or others if this
ruling goes through.
Yousuf Khan
