details about dual-core Yonah emerge

[YKhan]

Looks like it will contain a shared L2 cache, but no 64-bit yet. No
64-bit until "the market requires it". Sort of like what kept Windows
x64 from coming out until now; but now that x64 is already out, not
sure how Intel can prevent the market from requiring it anymore.

Intel spills beans on Yonah, the next notebook chip | CNET News.com
http://news.com.com/Intel+spills+beans+on+Yonah,+the+next+notebook+chip/2100-1006_3-5729925.html

Yousuf Khan

 

[Felger Carbon]

Looks like it will contain a shared L2 cache, but no 64-bit yet. No
64-bit until "the market requires it". Sort of like what kept Windows
x64 from coming out until now; but now that x64 is already out, not
sure how Intel can prevent the market from requiring it anymore.

Yousuf, I thought Celerons were now routinely shipping with x64
enabled. *If* that's right, there must be something else blocking x64
from Yonah.

 

[Jason Gurtz]

enabled. *If* that's right, there must be something else blocking x64
from Yonah.

More than likely there'd be more power draw; definitely a no-no in a
laptop. This thing sure looks like it'll be a real screamer.

From everything I've seen it looks like longhorn will be fully supported
in 32bit and x64 flavors so I don't really see lack of this feature as too
big a deal. Only another year and a half or so to merom...

~Jason

--

 

[Yousuf Khan]

Yousuf, I thought Celerons were now routinely shipping with x64
enabled. *If* that's right, there must be something else blocking x64
from Yonah.

Hard to say, well the Celeron-D's are of course based off of the
Prescott core which already has x64.

Another possibility is that it seems like the Netburst chips are like
old American V8 car engines from the 50's and 60's. There wasn't a lot
of subtlety built into those things, and there was lots of room for
aftermarket improvement. You could drop a 64-bit module into the
Netburst like you could drop a bigger carb into one of those old
engines. But the Pentium M is like a highly integrated European engine,
where changing even a small pipe might throw it's balance off. Just my
speculation.

Yousuf Khan

 

[gaf1234567890]

More than likely there'd be more power draw; definitely a no-no in a
laptop. This thing sure looks like it'll be a real screamer.

From everything I've seen it looks like longhorn will be fully supported
in 32bit and x64 flavors so I don't really see lack of this feature as too
big a deal. Only another year and a half or so to merom...

I agree. The question isn't just when will 64 bit software be
available, but when will 32 bit software *not* be available. I think it
will be a while before having a 64 bit notebook with greater than 4gb
ram is a necessity.

With all the existing 32bit systems in the world right now it might be
a decade or more before you absolutely can't buy a given app or OS in
32bit flavor.

 

[Yousuf Khan]

On 6/2/2005 20:52, Felger Carbon wrote:
More than likely there'd be more power draw; definitely a no-no in a
laptop. This thing sure looks like it'll be a real screamer.

Why do you think 64-bit would require more power draw?

Yousuf Khan

 

[epaton]

I agree. The question isn't just when will 64 bit software be
available, but when will 32 bit software *not* be available. I think it
will be a while before having a 64 bit notebook with greater than 4gb
ram is a necessity.

With all the existing 32bit systems in the world right now it might be
a decade or more before you absolutely can't buy a given app or OS in
32bit flavor.

yeah but since when does the consumer care about stuff like that, all a
sales guy has to say is this laptop is 32bit while the amd over there is
64 and they will take the higher number.

it may not be a real issue but when you have two like priced processors
and one wouln't run a lot of major software i recon it will have trouble.

 

[Robert Myers]

Yousuf, I thought Celerons were now routinely shipping with x64
enabled. *If* that's right, there must be something else blocking x64
from Yonah.

Not Pentium-M architecture, though--one guesses that Intel just
doesn't have 64-bit designed in.

I'd agree, though that Intel is up to something here, other than
design costs.

RM

 

[nobody]

Not Pentium-M architecture, though--one guesses that Intel just

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Which is not much more than just another incarnation of old good P6
architecture, that started as PPro around 1995, IIRC. At that time,
16 bit was the king, and it was not too far away from the (in)famous
B.G. blurp about 640k RAM being enough for everyone. 4 GB was the
number not yet passed by mainstream harddrives. Nobody even thought
about 64 bit back then...

 

[Yousuf Khan]

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Which is not much more than just another incarnation of old good P6
architecture, that started as PPro around 1995, IIRC. At that time,
16 bit was the king, and it was not too far away from the (in)famous
B.G. blurp about 640k RAM being enough for everyone. 4 GB was the
number not yet passed by mainstream harddrives. Nobody even thought
about 64 bit back then...

What are you talking about? 32-bit was around for at least ten years
prior to that, with the 386 in 1985. The P6 architecture was about the
fourth generation of 32-bit chips in the x86 line: 386, 486, Pentium P5,
and Pentium P6. Pentium 4 represents the fifth generation of 32-bit, and
Intel's first generation of x64.

Yousuf Khan

 

[nobody]

What are you talking about? 32-bit was around for at least ten years
prior to that, with the 386 in 1985. The P6 architecture was about the
fourth generation of 32-bit chips in the x86 line: 386, 486, Pentium P5,
and Pentium P6. Pentium 4 represents the fifth generation of 32-bit, and
Intel's first generation of x64.

Yousuf Khan

I am only remembering the times when was released P6 core, the one on
which Pentium M is largely based.
Software-wise, it was the year of the first consumer-level OS (win95)
introduction (marginal players like Mac, PS/2 etc. didn't count much).
Even that was largely 16 bit DOS with some 32 bit extensions on top of
it. More so, corporate desktops also were mostly DOS/WIN3.x, with
NT3.51 and flavors of *NIX being marginal players, until the
introduction of NT4.0 about a year later. The ability of 386 to run
32 bit code mostly went unused.
My point is - back then nobody seriously thought about 64-bitness, and
this is what makes near impossible to tack AMD64 onto P6-based PM core
developed around that time.

 

[YKhan]

I am only remembering the times when was released P6 core, the one on
which Pentium M is largely based.
Software-wise, it was the year of the first consumer-level OS (win95)
introduction (marginal players like Mac, PS/2 etc. didn't count much).
Even that was largely 16 bit DOS with some 32 bit extensions on top of
it. More so, corporate desktops also were mostly DOS/WIN3.x, with
NT3.51 and flavors of *NIX being marginal players, until the
introduction of NT4.0 about a year later. The ability of 386 to run
32 bit code mostly went unused.

I don't think it was quite as primitive back then as you think it was.

My point is - back then nobody seriously thought about 64-bitness, and
this is what makes near impossible to tack AMD64 onto P6-based PM core
developed around that time.

Yet, they were able to add all kinds of power management circuitry into
this core, which it was not originally designed to take either.

Yousuf Khan

 

[Jason Gurtz]

Why do you think 64-bit would require more power draw?

Well, I was thinking that it would represent a "hacked" addition of the
feature to satisfy PHB types at the last moment since this amd64 thing got
rushed into the market and there wouldn't really be an optimal
implementation from Intel until the generation after yonah.

~Jason

--

 

[Jason Gurtz]

What are you talking about? 32-bit was around for at least ten years
prior to that, with the 386 in 1985. The P6 architecture was about the
fourth generation of 32-bit chips in the x86 line

Wasn't the P6 the first 32-bit generation that was much more efficient at
executing 32-bit code? Or was it that P6 was just more inefficient at
executing 16-bit code?

I ask because I think I remember benchmarks at the then fledgling THG
that directly compared PPro 200 with a Pentium 200MMX that showed that
kind of oddity. Of course, I could be totally off base here; it seems so
long ago.

~Jason

--

 

[YKhan]

Wasn't the P6 the first 32-bit generation that was much more efficient at
executing 32-bit code? Or was it that P6 was just more inefficient at
executing 16-bit code?

Well the 486 was much more efficient at running 32-bit code than the
386. The Pentium was better than the 486. And the PPro was better than
the Pentium.

But yes, there was a tiny drop off in performance at 16-bit code when
using the PPro compared to the previous Pentium. That was due to the
fact that there wasn't a segment register cache in the PPro. However,
the next chip in the same family as PPro, the PII, rectified that by
adding that cache back in again.

Yousuf Khan

 

[YKhan]

Well, I was thinking that it would represent a "hacked" addition of the
feature to satisfy PHB types at the last moment since this amd64 thing got
rushed into the market and there wouldn't really be an optimal
implementation from Intel until the generation after yonah.

Well, they are making other changes to the architecture in the
meantime, so they might as well add the 64-bit instructions. However,
from what I hear about P-M, it's got power management circuits that
turn off disused parts of the chip. So it's likely that adding the
64-bit instructions would require moving some of these circuits out of
the way too.

Yousuf Khan

 

[Jason Gurtz]

Ahh, a long standing mystery (to me) finally solved

~Jason

--

 

[keith]

Well the 486 was much more efficient at running 32-bit code than the
386. The Pentium was better than the 486. And the PPro was better than
the Pentium.

But yes, there was a tiny drop off in performance at 16-bit code when
using the PPro compared to the previous Pentium. That was due to the
fact that there wasn't a segment register cache in the PPro.

It was *not* in any way "tiny". It was a significant performance hit, so
much so that the P6 was unsuable in Win. To be fair, it was supposed to
be a server chip and 32bit only.

However, the next chip in the same family as PPro, the PII, rectified that by
adding that cache back in again.

I thought they renamed the segment registers, rather than cache them, per
se. Felg has the skinny here.

 

[Tony Hill]

Wasn't the P6 the first 32-bit generation that was much more efficient at
executing 32-bit code? Or was it that P6 was just more inefficient at
executing 16-bit code?

The Pentium Pro was lacking one small feature that hurt performance in
16-bit code by about 10-15%. This feature was added back to the
architecture with the PII.

Note that referring to the Pentium-M and the PentiumPro as being of
the same architecture is really stretching things. While the
Pentium-M might be able to trace it's roots back to the PentiumPro,
the two chips are VERY different in virtually every aspect.

 

[Jason Gurtz]

much so that the P6 was unsuable in Win.

It was pretty good with NT 4.0

~Jason

--