details about dual-core Yonah emerge

G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

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%2C+the+next+notebook+chip/2100-1006_3-5729925.html

Yousuf Khan
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

"YKhan" <yjkhan@gmail.com> wrote in message
news:1117753915.086516.302940@g14g2000cwa.googlegroups.com...
> 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.
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

Jason Gurtz wrote:
> On 6/2/2005 20:52, Felger Carbon wrote:
>
> > 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...
>


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.
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On 6/2/2005 20:52, Felger Carbon wrote:

> 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

--
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

Felger Carbon wrote:
> 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
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

Jason Gurtz wrote:
> 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
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Fri, 03 Jun 2005 00:52:05 GMT, "Felger Carbon" <fmsfnf@jfoops.net>
wrote:

>"YKhan" <yjkhan@gmail.com> wrote in message
>news:1117753915.086516.302940@g14g2000cwa.googlegroups.com...
>> 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.
>

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
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

>
> 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.
 

mygarbage2000

Distinguished
Jun 5, 2002
126
0
18,680
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Sat, 04 Jun 2005 09:58:17 -0400, Robert Myers
<rmyers1400@comcast.net> wrote:

>On Fri, 03 Jun 2005 00:52:05 GMT, "Felger Carbon" <fmsfnf@jfoops.net>
>wrote:
>
>>"YKhan" <yjkhan@gmail.com> wrote in message
>>news:1117753915.086516.302940@g14g2000cwa.googlegroups.com...
>>> 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.
>>
>
>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...
>doesn't have 64-bit designed in.
>
>I'd agree, though that Intel is up to something here, other than
>design costs.
>
>RM
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

nobody@nowhere.net wrote:
>>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...

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
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

nobody@nowhere.net wrote:
> 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
 

mygarbage2000

Distinguished
Jun 5, 2002
126
0
18,680
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Sun, 05 Jun 2005 13:25:41 -0400, Yousuf Khan <bbbl67@ezrs.com>
wrote:

>nobody@nowhere.net wrote:
>>>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...
>
>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.
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

Jason Gurtz wrote:
> 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
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

Jason Gurtz wrote:
> On 6/3/2005 21:08, Yousuf Khan wrote:
>
> > 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.

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
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On 6/3/2005 21:08, Yousuf Khan wrote:

> 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

--
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On 6/5/2005 13:25, Yousuf Khan wrote:
> 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

--
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

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

~Jason

--
 

keith

Distinguished
Mar 30, 2004
1,335
0
19,280
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Mon, 06 Jun 2005 12:57:07 -0700, YKhan wrote:

> Jason Gurtz wrote:
>> 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.

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.

--
Keith
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Mon, 06 Jun 2005 15:23:14 -0400, Jason Gurtz <ask@NOmeSPAM.where>
wrote:

>On 6/5/2005 13:25, Yousuf Khan wrote:
>> 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?

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.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

keith wrote:
> On Mon, 06 Jun 2005 12:57:07 -0700, YKhan wrote:
> > 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.

It was around a 5% drop as I recall. I remember reading it at the time,
and thinking it was much ado about nothing.

> > 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.

If they used register renaming then that's a form of caching the
registers anyways.

Yousuf Khan
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On 6/6/2005 22:01, keith wrote:

> much so that the P6 was unsuable in Win.

It was pretty good with NT 4.0

~Jason

--
 

keith

Distinguished
Mar 30, 2004
1,335
0
19,280
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Tue, 07 Jun 2005 13:32:33 -0400, Jason Gurtz wrote:

> On 6/6/2005 22:01, keith wrote:
>
>> much so that the P6 was unsuable in Win.
>
> It was pretty good with NT 4.0

....and NT4 was available when PPro shipped? It really wasn't that great
with NT4. The PII would be a more contemporary comparison. ...and NT4
wasn't a screamer.

--
Keith
 

keith

Distinguished
Mar 30, 2004
1,335
0
19,280
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Tue, 07 Jun 2005 12:12:00 -0700, YKhan wrote:

> keith wrote:
>> On Mon, 06 Jun 2005 12:57:07 -0700, YKhan wrote:
>> > 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.
>
> It was around a 5% drop as I recall. I remember reading it at the time,
> and thinking it was much ado about nothing.

It was far woese than that. The PPro was slower than the P5. Segment
register reloads were *expensive*, and they're all over Win9x.

>> > 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.
>
> If they used register renaming then that's a form of caching the
> registers anyways.

A maggot is a form of a fly too.

--
Keith
 

keith

Distinguished
Mar 30, 2004
1,335
0
19,280
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Mon, 06 Jun 2005 22:52:50 -0400, Tony Hill wrote:

> On Mon, 06 Jun 2005 15:23:14 -0400, Jason Gurtz <ask@NOmeSPAM.where>
> wrote:
>
>>On 6/5/2005 13:25, Yousuf Khan wrote:
>>> 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?
>
> 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.

I don't think this is quite accurate. The PPro was not *supposed* to
execute 16bit code, thus the architects didn't see any harm in making
segment register reloads expensive. They *added* the segment register
renaming (cacheing) to ameliorate this problem, in the PII. Anyway, if
you can wake up Felg, he has the real deal. I looked through my email
archives and couldn't find the info.

> 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.

Gee, I thought all Intel's been doing for a couple of decades is
cranking up the clock! ;-)

--
Keith
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Mon, 06 Jun 2005 22:01:03 -0400, keith <krw@att.bizzzz> wrote:

>On Mon, 06 Jun 2005 12:57:07 -0700, YKhan wrote:
>
>> Jason Gurtz wrote:
>>> 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.
>
>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.

Come now Keith, that's a HUGE exaggeration. The drop in performance
really was TINY, and yes I did use some PPro systems in Win95.
Honestly a PPro 200MHz with 256KB of cache was about 10-15% slower
than a Pentium 200 in most 16-bit Win95 apps, and it was FASTER any
time you started running any 32-bit Win95 apps (of which there were
quite a number when these chips were common) and MUCH faster as soon
as you hit any heavy 32-bit FP code.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca