<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
> Intel started it first with picking up a ridiculous number for the family
> ID for the P4 line. There is no technical justification for not keeping
> these numbers consecutive.=20
Well=2C the problem was that Intel has assigned family 7 for the original I=
tanium processor=2C back when Intel thought that would replace x86 (the cod=
ename for the original Itanium was P7=2C and the codename for the original =
P4 was P68). And then there was a bug in original NT 4 truncating family ID=
s returned by CPUID to 3 bits. This was not the only bug in the original NT=
4's CPUID code=2C there was another bug relating to CX8 detection with non=
-Intel/AMD/Cyrix processors forcing the other CPU vendors to provide an opt=
ion to mask this bit=2C which caused trouble for MS itself later on when th=
ey decide they would begin to require CX8 in XP=2C and it ignores CPUID if =
max standard CPUID level is greater than 3=2C forcing Intel to again add a =
workaround into their Prescott and later processors.
Geoff Chappell wrote articles describing these problems in NT 4:
http://geoffchappell.com/viewer.htm?doc=3Dstudies/windows/km/cpu/index.htm
http://geoffchappell.com/viewer.htm?doc=3Dstudies/windows/km/cpu/cx8.htm
Yuhong Bao
=20
_________________________________________________________________
Windows 7: It helps you do more. Explore Windows 7.
http://www.microsoft.com/Windows/windows-7/default.aspx?ocid=3DPID24727::T:=
WLMTAGL:ON:WL:en-US:WWL_WIN_evergreen3:102009=
On Wednesday 2009-10-28 04:08, Yuhong Bao wrote:
> <[email protected]>
>
>> Intel started it first with picking up a ridiculous number for the family
>> ID for the P4 line. There is no technical justification for not keeping
>> these numbers consecutive.
Once one knows that there are 4 bits for the family field, 15 is not
such a strange value - it is the last value, one could take it as
"reserved, and look elsewhere".
>[...] Intel has assigned family 7 for the original Itanium processor
>[...] there was a bug in original NT 4 truncating family IDs
>returned by CPUID [...]
That would explain why Intel still shows an oldfashioned family=6 on
many contemporary processors (e.g. core i7). BUT, AMD64 processors
have family=15 "almost throughout", and so seem to have at least some
Intel models. So that tells us that either NT4 works, or nobody uses
NT4 on fam15s.
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
> On Wednesday 2009-10-28 04:08=2C Yuhong Bao wrote:
>>=20
>>
>>> Intel started it first with picking up a ridiculous number for the fami=
ly
>>> ID for the P4 line. There is no technical justification for not keeping
>>> these numbers consecutive.
>
> Once one knows that there are 4 bits for the family field=2C 15 is not
> such a strange value - it is the last value=2C one could take it as
> "reserved=2C and look elsewhere".
Indeed=2C as I said=2C AMD began to use the extended family field with the =
K10.
>>[...] Intel has assigned family 7 for the original Itanium processor
>>[...] there was a bug in original NT 4 truncating family IDs
>>returned by CPUID [...]
>
> That would explain why Intel still shows an oldfashioned family=3D6 on
> many contemporary processors (e.g. core i7). BUT=2C AMD64 processors
> have family=3D15 "almost throughout"=2C and so seem to have at least some
> Intel models.=A0See my second mailing post message for why.
> So that tells us that either NT4 works=2C or nobody uses
> NT4 on fam15s.Family 15 truncated to 3 bits is family 7=2C which do work =
with NT 4=2C while family 8 truncated to 3 bits is family 0.
Yuhong bao =20
_________________________________________________________________
Windows 7: Simplify your PC. Learn more.
http://www.microsoft.com/Windows/windows-7/default.aspx?ocid=3DPID24727::T:=
WLMTAGL:ON:WL:en-US:WWL_WIN_evergreen1:102009=
On Wed, Oct 28, 2009 at 09:30:33AM +0100, Jan Engelhardt wrote:
> So that tells us that either NT4 works, or nobody uses
> NT4 on fam15s.
Or that no-one cares.
I don't know why this year and half old thread was resurrected,
but can we all do our bit for lkml traffic reduction and let it die?
(or at least drop me from the cc. The bug was fixed May 2008,
there's no reason afaics for endless bibble filling everyones inbox).
Dave
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
>> So that tells us that either NT4 works=2C or nobody uses
>> NT4 on fam15s.
>
> Or that no-one cares.
NT 4 do work on fam15s=2C because 15 truncated to 3 bits is 7=2C while 8 tr=
uncated to 3 bits is 0.
> I don't know why this year and half old thread was resurrected=2C
> but can we all do our bit for lkml traffic reduction and let it die?
> (or at least drop me from the cc. The bug was fixed May 2008=2C
> there's no reason afaics for endless bibble filling everyones inbox).
=A0I know that this bug is now fixed=2C but=A0I wanted to provide more deta=
il on the history behind this.
Yuhong Bao =20
_________________________________________________________________
Windows 7: Simplify your PC. Learn more.
http://www.microsoft.com/Windows/windows-7/default.aspx?ocid=3DPID24727::T:=
WLMTAGL:ON:WL:en-US:WWL_WIN_evergreen1:102009=