• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Conroe has limitation on 64 Bit Mode

Page 2 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
Originally posted by: keysplayr2003
Originally posted by: RichUK
Originally posted by: Black69ta
I know that Woodcrest is based on Core design also, but isn't Itanium II already 64bit enhanced for server/enterprise market. so wouldn't it be logical that woodcrest will be 64bit optimized too, and thus it would be dumb of Intel to spend the money and or transistors to make "home" C2D's blaze in a 64bit environment when none of the software is there to exploit it. And when PC went from 32bit from 16bit didn't 16bit take a "hit" on 32bit systems? So I can see why Intel doesn't care. Like someone said above, it won't be needed for several more generational steps

Itanium processors are based on Intel's IA64 Instruction Set (based on the RISC Architecture), where as Intel's and AMD's mainstream processors are based on the x86 architecture.

Itanium has to software emulate an x86 working processor in order to run x86 coded software. Aka pretty much all software available today.

Windows and other software vendors have specifically created versions of their software to be ran on the Intel Itanium processors.

Basically this processor has no use to the average user, or mid ranged user either, considering the lack of software support.

I think they call it "EPIC", Rich. Love your sig by the way!! :thumbsup:

😀
 
Originally posted by: dmens
Originally posted by: jose
So it looks like Conroe has the same pathetic 64bit implementation that plagued Intel's prior chips.

http://www.theinquirer.net/default.aspx?article=16879
Regards,
Jose

LOL! That's a nocona, not a conroe. And I'll give you a cookie when you can explain to me how it is broken... or pathetic, for that matter.

As for the conroe rumor, it made no sense whatsoever, so it really sounds like another piss poor "fake 64-bit on intel" rumor.


I agree. This is just another attempt to "save AMD from bankruptcy" article. :laugh:



All kidding aside, this article has no credibility.
 
My point was was that in order to optimize 64bit performance, 32bit would suffer just like systems did when Pentiums were introduced. and yes Vista will be partially 64bit but it will not even be optimized for 64bit just a little 64bit "flavor", if you youngster can remeber Win95 touted its 32bit capabilities but if anyone wanted real 32bit OSes you had to use NT. did Win98 or 98SE bring "pure" 64bit OS to "Homes" no. Windows2000? yes but it was really Nt glorified with win98 componets and NTFS, then the Y2k savior appeared called WinMe But low and Behold it was only win98 with NT flavors, (but NTFS still missing). the problem was that Software and more importantly "home users" were not ready for a "pure" 32bit OS until XP came along. Now Vista promises 64bit performance, but then it also promised WinFS. So I would really be curious if any body here could set up two systems (one Athlon64, and one a non 64bit P4) that would do Most if not all benchmarks on XP pretty much evenly. then install Vista and see if the 64extensions that AMD has bragged about will even make any difference or if so how much. My guess would be maybe 5% at most. I think that 64bit XP's were just a marketing ploy. even if it does help more what software is there that's 64bit. WinXP 64bit, WoW 64bit edition, no wait that was just a pipe dream there is no 64bit edition of any software except maybe in the enterprise sector. So why would Intel care if the C2D can do 64bit at all, they have 64bit solutions for the people who need them, with the Itanium and Xeon so why would they waste resources on Home PCs. Software writers are historically Slowwer than Molasses at rewriting all their code to implement new tech. so others are probably right in thinking it will be a year or more before 64bit software shows up substantially and even longer before its prevalent. so Who cares if Conroe isn't 30% faster then A64 at one thing, When is the last time that any Manufacter put out a new CPU Family that was 30% faster then the current performance king, Maybe the Pentium was 305 faster then the 486? any way my PIII 933 is almost as good as my Mothers P4 1.4 Wow sorry for the long rant I just could shut up.
 
Originally posted by: FelixDeKat
Originally posted by: dmens
Originally posted by: jose
So it looks like Conroe has the same pathetic 64bit implementation that plagued Intel's prior chips.

http://www.theinquirer.net/default.aspx?article=16879
Regards,
Jose

.

LOL! That's a nocona, not a conroe. And I'll give you a cookie when you can explain to me how it is broken... or pathetic, for that matter.

As for the conroe rumor, it made no sense whatsoever, so it really sounds like another piss poor "fake 64-bit on intel" rumor.


I agree. This is just another attempt to "save AMD from bankruptcy" article. :laugh:



All kidding aside, this article has no credibility.

The article is credible and I've confirmed this w/ Red Hat support Engineers in regards to Intel's processors at that time. The main reason I brought up the article is to show how long Intel knew it had a pathetic 64bit implementation.

I've been using/building servers for 18yrs, exclusively Intel.
But in the last year I've switched to Opteron based servers.

So all you fanboys get a life.

The fact is Conroe is a very fast processor, probably faster than anything AMD has currently.

But it's 64bit memory addressing sucks.

The same needs to apply to all the AMD fanboys, give Intel it's due. Nice to have some competition, this will only benefit us in the long run.

If it wasn't for competition, we'd all be running P2's , do any
of you remember when 33mhz increase in speed was a big deal. ie. pent 100, 133, etc.

Now the 64bit addressing doesn't affect the average user, but when it comes to servers it's a big deal.

Now that said, I'll more than likely get a conroe setup to go along w/ my Opteron 170 system.

Regards,
Jose
 
And just how is Intel supposed to add hardware support for IOMMU without an integrated memory controller? It's coming.. but is not here yet.

And for the record, there are many servers and server applications that don't need and aren't using 64-bit extensions. The claim that this missing feature is a "big deal" to everything servers is ridiculous.
 
You've been using/building servers for 19 years and didn't know that x86-64 architecture only physically addresses 40bits of memory? As for the article you mentioned, its been addressed by RedHat above a dozen kernel revisions ago.

FYI, pentium 100->133 was a 33% increase in speed. That would be the clock speed equilvalent of a 3800+ to 5000+.
 
Originally posted by: FelixDeKat
Originally posted by: dmens
Originally posted by: jose
So it looks like Conroe has the same pathetic 64bit implementation that plagued Intel's prior chips.

http://www.theinquirer.net/default.aspx?article=16879
Regards,
Jose

LOL! That's a nocona, not a conroe. And I'll give you a cookie when you can explain to me how it is broken... or pathetic, for that matter.

As for the conroe rumor, it made no sense whatsoever, so it really sounds like another piss poor "fake 64-bit on intel" rumor.


I agree. This is just another attempt to "save AMD from bankruptcy" article. :laugh:



All kidding aside, this article has no credibility.

Right, because AMD is really going to go backrupt... lol
 
Neither AMD nor Intel produce a true 64bit chip based on x86. The only true 64bit chip from either company is the Itanium IA64, which is a through and through 64bit operational processor.

Although both K8 and Conroe can run 64bit code, neither processor can physically address 64bits of physical memory, this is the only part that negates a true 64bit CPU in this case.

As devx has already stated, AMD only address's 40bits (which is one terabyte of physical address space :shocked: ), and Intel i believe can only address to 36 bits which is 64 gig of physical memory.

32bit addressing as we know only allows upto 4096MB's of physical addressing.

At the end of the day, until MS release their new OS which is designed from the bottom up to work with 64bit addressing. People are forced to use the PAE switch in order to utilise upto 64GB's of physical memory in 32bit mode. Or use XP64.

The only thing that differentiates the two processors in 64bit processing ATM, is the way in which its 64bit processing is implemented into the processor core itself. With a K8 Vs Netburst implementation of 64bit processing, I think it has already been documented that AMD had the better implementation.

I?ll see if I can pull up any links that quantifies what I say, about AMD having a better implementatio.

Anyways, lol I have 1GB of memory in my comp, I think MS datacentre OS?s can address upto 128GB?s of physical address space using the PAE switch (Physical Address Extension switch in the BOOT.INI string).

At this current time AMD have the upper hand on 64bit processing against its netburst counterpart, and can also address to more physical memory. I wonder whether Conroe will be able to perform better than AMD?s K8 in 64bit processing once it is released.
 
Originally posted by: jose
The article is credible and I've confirmed this w/ Red Hat support Engineers in regards to Intel's processors at that time. The main reason I brought up the article is to show how long Intel knew it had a pathetic 64bit implementation.

But it's 64bit memory addressing sucks.

that's odd, last I checked, upper 20-ish msb of the address busses were fused off in every x86-64 chip there is. So much for "64-bit addressing", and it's supposed pathetic implementation on conroe... or is it nocona, which chip are you talking about here anyways? LOL.
 
Originally posted by: RichUK
Neither AMD nor Intel produce a true 64bit chip based on x86. The only true 64bit chip from either company is the Itanium IA64, which is a through and through 64bit operational processor.

what the heck is a true 64-bit chip? expanded physical space is just a bonus of AMD64/EM64T, and it's not fully accessible to begin with.
 
Originally posted by: dmens
Originally posted by: RichUK
Neither AMD nor Intel produce a true 64bit chip based on x86. The only true 64bit chip from either company is the Itanium IA64, which is a through and through 64bit operational processor.

what the heck is a true 64-bit chip? expanded physical space is just a bonus of AMD64/EM64T, and it's not fully accessible to begin with.

lol you work for Intel and ask a question like this.

Well

1. 64 bit Integer calculations in hardware.
2. 72 bit IEEE-1180 Floating Point calculations in hardware.
3. 64 bit virtual address space.
 
Originally posted by: RichUK
As devx has already stated, AMD only address's 40bits (which is one terabyte of physical address space :shocked: ), and Intel i believe can only address to 36 bits which is 64 gig of physical memory.

No, thats the definition of x86-64 so far. The 36bit addressing was actually done by the older P3-Xeons and early Willamette/Northwood based P4's that used PAE. It was just awefully slow.

I'm not sure where the Nocona x86-64 crap performance comes from. From the stuff I've seen, they have minor across the board gains on average.
 
Originally posted by: RichUK
lol you work for Intel and ask a question like this.

Well

1. 64 bit Integer calculations in hardware.
2. 72 bit IEEE-1180 Floating Point calculations in hardware.
3. 64 bit virtual address space.

i ask because your definition is vague and arbitrary, and so is your explanation. so ignoring that, why does the lack of a 64-bit integer stack make a chip any less capable at 64-bit functionality? it is very possible to meet the 64-bit extension spec without anything you specified, with some clever microcoding. would such an implementation be any less true than otherwise? i think not.
 
Originally posted by: dexvx
Originally posted by: RichUK
As devx has already stated, AMD only address's 40bits (which is one terabyte of physical address space :shocked: ), and Intel i believe can only address to 36 bits which is 64 gig of physical memory.

No, thats the definition of x86-64 so far. The 36bit addressing was actually done by the older P3-Xeons and early Willamette/Northwood based P4's that used PAE. It was just awefully slow.

I'm not sure where the Nocona x86-64 crap performance comes from. From the stuff I've seen, they have minor across the board gains on average.

I'm not following you on this. The amount of memory X86-64 processors can address to is not the definition of x86-64.

The PAE function is controlled by the OS Kernel. All you need is a processor that is capable of 36bit addressing. aka Intel's netburst and AMD's K8 processors, i wasn't debating whether P3's could or not.
 
Originally posted by: dmens
Originally posted by: RichUK
lol you work for Intel and ask a question like this.

Well

1. 64 bit Integer calculations in hardware.
2. 72 bit IEEE-1180 Floating Point calculations in hardware.
3. 64 bit virtual address space.

i ask because your definition is vague and arbitrary, and so is your explanation. so ignoring that, why does the lack of a 64-bit integer stack make a chip any less capable at 64-bit functionality? it is very possible to meet the 64-bit extension spec without anything you specified, with some clever microcoding. would such an implementation be any less true than otherwise? i think not.

Considering i don?t work for Intel nor AMD i'm afraid i cant answer that, but i find your argument pretty lame. From what i have read most processors can perform 72bit floating point calculations, and as that is the only IEEE requirement, it wouldn't be that hard to brand a processor 64bit, due to technicality.

Also you mention this microcoding that could act as a work around, would you then deem this as a 64 bit chip even though it would be running in an 32 bit environment? I think not. (I still assume you will argue the technicality). Also is this your definition of a 64bit processor?



Also just to nit pick, since you really should clarify what you state.

expanded physical space is just a bonus of AMD64/EM64T, and it's not fully accessible to begin with.

From what I have read, AMD and Intel are not able to access the full 64bit addressing anyway, since the transistors that would be used for full 64bit support haven?t been used, so to save on die space. The reason being, why add support for something that will not be available in its era. Aka >1TB of physical memory.

Ill see if I can pull up the article I read on that too.
 
Originally posted by: RichUK
Considering i don?t work for Intel nor AMD i'm afraid i cant answer that, but i find your argument pretty lame. From what i have read most processors can perform 72bit floating point calculations, and as that is the only IEEE requirement, it wouldn't be that hard to brand a processor 64bit, due to technicality.

Also you mention this microcoding that could act as a work around, would you then deem this as a 64 bit chip even though it would be running in an 32 bit environment? I think not. (I still assume you will argue the technicality). Also is this your definition of a 64bit processor?

From what I have read, AMD and Intel are not able to access the full 64bit addressing anyway, since the transistors that would be used for full 64bit support haven?t been used, so to save on die space. The reason being, why add support for something that will not be available in its era. Aka >1TB of physical memory.

Ill see if I can pull up the article I read on that too.

Which of my arguments is lame again? I don't even know why you dragged float into this, since it uses a variable data field depending on backend implementation. But in regards to integer (and addressing), why would you care if the entire backend is 32-bit, or 8-bit, or whatever. I assume that is what you mean by a "32-bit environment". As long as the visible machine meets the specification on 64-bit extensions, that is fine with me.

So the term "true 64-bit impelemtation" is crap, becasuse it implies there are procs out there that fail to meet the spec. Marketing FUD, all of it.

As for the full addressing, the logic for the upper msb is there, it is tied off and unused.
 
Originally posted by: dmens
Originally posted by: RichUK
Considering i don?t work for Intel nor AMD i'm afraid i cant answer that, but i find your argument pretty lame. From what i have read most processors can perform 72bit floating point calculations, and as that is the only IEEE requirement, it wouldn't be that hard to brand a processor 64bit, due to technicality.

Also you mention this microcoding that could act as a work around, would you then deem this as a 64 bit chip even though it would be running in an 32 bit environment? I think not. (I still assume you will argue the technicality). Also is this your definition of a 64bit processor?

From what I have read, AMD and Intel are not able to access the full 64bit addressing anyway, since the transistors that would be used for full 64bit support haven?t been used, so to save on die space. The reason being, why add support for something that will not be available in its era. Aka >1TB of physical memory.

Ill see if I can pull up the article I read on that too.

Which of my arguments is lame again? I don't even know why you dragged float into this, since it uses a variable data field depending on backend implementation. But in regards to integer (and addressing), why would you care if the entire backend is 32-bit, or 8-bit, or whatever. I assume that is what you mean by a "32-bit environment". As long as the visible machine meets the specification on 64-bit extensions, that is fine with me.

So the term "true 64-bit impelemtation" is crap, becasuse it implies there are procs out there that fail to meet the spec. Marketing FUD, all of it.

As for the full addressing, the logic for the upper msb is there, it is tied off and unused.

So your saying that at the very least, you would consider point 2 a 64bit processor, and you would be fine calling a processor 64 bit if it met the criteria of points 2 and 3.

1. 64 bit Integer calculations in hardware.
2. 72 bit IEEE-1180 Floating Point calculations in hardware.
3. 64 bit virtual address space.

How the hell can you class that as a 64bit processor if it's only capable of 64bit physical addressing, but not actually PROCESSING 64bit code.

Thats what i think is a lame argument, when you argue technicality, when that is not the actual ideals of AMD or Intel.

The PAE switch used by MS In their OS is just a work around, so that a 32bit processor can address to more memory.

I mean you could use a normal K8, that is capable of 128bit physical addressing, would you then deem that as a 128bit processor, even though the core process?s in 32bit.
 
Originally posted by: RichUK
So your saying that at the very least, you would consider point 2 a 64bit processor, and you would be fine calling a processor 64 bit if it met the criteria of points 2 and 3.

1. 64 bit Integer calculations in hardware.
2. 72 bit IEEE-1180 Floating Point calculations in hardware.
3. 64 bit virtual address space.

How the hell can you class that as a 64bit processor if it's only capable of 64bit physical addressing, but not actually PROCESSING 64bit code.

Thats what i think is a lame argument, when you argue technicality, when that is not the actual ideals of AMD or Intel.

The PAE switch used by MS In their OS is just a work around, so that a 32bit processor can address to more memory.

I mean you could use a normal K8, that is capable of 128bit physical addressing, would you then deem that as a 128bit processor, even though the core process?s in 32bit.

When did I say anything about not being able to process 64-bit code? That is part of the specification right? All I'm saying is that you don't need a 64-bit hardware datapath to meet the specification. As such, there is no such thing as a true (or false) 64-bit processor, just ones that meet a spec. That is all.
 
Originally posted by: dmens
Originally posted by: RichUK
So your saying that at the very least, you would consider point 2 a 64bit processor, and you would be fine calling a processor 64 bit if it met the criteria of points 2 and 3.

1. 64 bit Integer calculations in hardware.
2. 72 bit IEEE-1180 Floating Point calculations in hardware.
3. 64 bit virtual address space.

How the hell can you class that as a 64bit processor if it's only capable of 64bit physical addressing, but not actually PROCESSING 64bit code.

Thats what i think is a lame argument, when you argue technicality, when that is not the actual ideals of AMD or Intel.

The PAE switch used by MS In their OS is just a work around, so that a 32bit processor can address to more memory.

I mean you could use a normal K8, that is capable of 128bit physical addressing, would you then deem that as a 128bit processor, even though the core process?s in 32bit.

When did I say anything about not being able to process 64-bit code? That is part of the specification right? All I'm saying is that you don't need a 64-bit hardware datapath to meet the specification. As such, there is no such thing as a true (or false) 64-bit processor, just ones that meet a spec. That is all.

The thing is, you tried to argue against my definition of a true 64 bit processor. I am still trying to work out your definition, after already asking you twice. From what you have stated, meeting the "64bit extensions" of x86-64 backs your definition of a 64bit processor, which I don?t quite understand the logic of. Since i originally stated that neither AMD nor Intel had a proper 64 bit processor except for the Itanium IA64, as it meets the criteria of all three points.

See this is the exact problem Intel have right now, where EMT64 should not be perceived to mean it is indeed a physical 64bit processor. As in reality it just emulates a 64bit processor (64bit registers) in a 32bit environment.

EMT64 should be perceived as a processor that is able to work in conjunction with an OS that schedules threads in 64bit mode, and a processor that can address more than 64GB of physical memory, and that will effectively emulate 64bit processing for this very task. My point being that it doesn?t physically process 64bit code as does the K8, and does emulate 64bit registers, as does all EMT64 Intel chips.

EDIT: And don?t ask me to provide proof as you did with jose as this is something I read ages ago from quite a few sources (so it would seem quite a strong rumour), be it rumour or not. Only way to prove this would be with Intel white papers, but we all know that ain?t going to happen.

And I think the previous two paragraphs bring us back to the statement jose made quite nicely

So it looks like Conroe has the same pathetic 64bit implementation that plagued Intel's prior chips

If correct then this means, Conroe is still a native 32bit processor (So poor performance with Vista 64bit me thinks). But the fact that 64 bit processing has no real impact as of yet for the consumer level market, I don?t think really makes a sh!t of difference.
 
OMG. What part of "meet x86-64/EM64T spec = 64-bit processor" doesn't make sense? What is wrong with that statement? Why does a chip need to meet those three arbitrary conditions to be a 64-bit chip?

On top of that, what emulation are you talking about? Hardware doesn't care about "environment". What is a 32-bit native processor, as opposed to 64-bits? Please explain. The front understands everything you toss its way, and the back simply doesn't care. In fact, most of the backend is greater than 64-bits data width to begin with, for many reasons.

Why do you keep saying EM64T "emulates" 64-bit registers? I assume you're walking about programmer visible. That has never been true, not with any incarnation of EM64T. On top of that, how does EM64T (any implementation) "not process" the new instructions attached to the spec? It most certainly does. What makes you think it doesn't?

And since you're including the op's original ridiculous statement of conroe having the same "pathetic" 64-bit implementation as previous EM64T enabled chips, please go ahead and explain to me how this "emulation", "native environment", and so forth works before telling me why EM64T is so bad.
 
Back
Top