Does Conroe emulate 64-bit or not?

xFlankerx

Limp Gawd
Joined
Oct 30, 2005
Messages
259
I have a relatively simple question - Does the Conroe processor still emulate 64-bit capability like the Pentium 4s, or is it now a truly 64-bit processor like AMD's Athlon 64s?
 
Conroe is real 64 bit. As was the P4. it was never an emulated thing. It can be argued that the implementation wasnt that good, but it was certainly "real"

As far as Conroe goes, it seems like a solid implementation. It should scale well with memory. And given the architectural enhancements made, it should be able to put thoise extra GPR's to good use as well. I think they did a pretty good job this time.
 
Well, technically the desktop chips that are 64-bit now aren't even "true" 64-bit.

..but yes, Conroe is "true" 64-bit.

edit: bah! too slow....laggy internet tonight

 
What are you talking about? Pentium 4's don't "emulate" 64-bit capability. You can't emulate something like that. Either you support it or you don't. EMT64 P4's are just as capable as the A64's in 64-bit code.

In order to support x86-64 the cpu must have 16 64-bit registers (as opposed to 8 32-bit registers as in x86) as well as a host of other new things, and that's the end of the story.
 
Chill, ladies, chill. I'm all for the Conroe, just trying to clear up some stuff. This is what I was told;

AMD64s are true 64 bit processors as they process 64 instruction sets both internally and natively. EM64T is different however; it's been demonstrated to only emulate 64 bit instruction sets through an internal 32 bit process. In other words, they aren't true 64 bit processors and thus as a result they bottleneck themselves as they have to keep emulating code that they can't really process in its native mode.

This issue isn't really relevant now as 64 bit code is almost non-existant, but this is probably going to change after Vista is released (and forgive me as I haven't really followed Vista at all). Now, 32 bit processes are only capable of addressing 2^32 bytes or roughly 4GB. Assuming Vista is the resource hog it is, we'll have to shift to 64 bit processes in order to obtain a larger addressing size (2^64 bytes). This will basically result in an internal memory bandwidth bottleneck in any EM64T processor as it has to keep switching between two instruction sets.
 
There were quite a few differences between AMD64 and EM64T with reguards to P4s. I think they have added most if not all of the things missing from the P4 chips. Note that a few of the entires say early P4 chips, these have already been added to later P4 CPUs.

Differences between AMD64 and EM64T (from Wikipedia) said:
* It is widely believed, and some would say demonstrable, that the Intel processors which utilize the EM64T instruction set, are actually 32 bits internally, while merely emulating x86-64 in microcode, whereas the AMD64 processors are physically 64 bits internally.

* Early AMD64 processors lacked the CMPXCHG16B instruction, which is an extension of the CMPXCHG8B instruction present on most post-486 processors. Similar to CMPXCHG8B, CMPXCHG16B allows for atomic operations on 128-bit double quadword (or oword) data types. This is useful for high resolution counters that could be updated by multiple processors (or cores). Without CMPXCHG16B the only way to perform such an operation is by using a critical section.

* Early Intel CPUs with EM64T lacked LAHF and SAHF instructions supported by AMD64 until introduction of Pentium 4 G1 step in December 2005. LAHF and SAHF are load/store instructions for status flags.

* Early Intel CPUs with EM64T also lack the NX bit (No Execute bit) of the AMD64 architecture. The NX bit marks memory pages as non-executable, allowing protection against many types of malicious code.

* SYSCALL and SYSRET are also only supported in IA-32e mode (not in compatibility mode) on EM64T. SYSENTER and SYSEXIT are supported in both modes.

* Near branches with the 0x66 (operand size) prefix behave differently. One type of CPU clears only the top 32 bits, while the other type clears the top 48 bits.

* EM64T's BSF and BSR instructions act differently when the source is 0 and the operand size is 32. The processor sets the zero flag and leaves the upper 32 bits of the destination undefined.

* AMD64 supports 3DNow! instructions. This includes prefetch with the opcode 0x0F 0x0D and PREFETCHW, which are useful for hiding memory latency.

* EM64T lacks the ability to save and restore a reduced (and thus faster) version of the floating-point state (involving the FXSAVE and FXRSTOR instructions). AMD64 is also able to execute most floating point instructions in a single clock cycle, making it an ideal candidate for massively parallel supercomputing applications.

* EM64T lacks some model-specific registers that are considered architectural to AMD64. These include SYSCFG, TOP_MEM, and TOP_MEM2.

* EM64T supports microcode update as in 32-bit mode, although it has been rumored that AMD processors have supported programmable microcode (an undocumented feature) for years.

* EM64T's CPUID instruction is very vendor-specific, as is normal for x86-style processors.

* The MONITOR and MWAIT instructions, used by operating systems to better deal with Hyper-threading, are only supported (and only useful) on EM64T.

* AMD64 systems allow the use of the AGP aperture as an IO-MMU. Operating systems can take advantage of this to let normal PCI devices DMA to memory above 4 GB. EM64T systems require the use of bounce buffers, which are slower.

* Originally EM64T hardware allowed access only to 236 bytes of memory, while AMD64 systems can handle up to 240 (planned expansion to 256) bytes. However, as of recent publications, EM64T now provides 240 bytes of memory access.
 
* It is widely believed, and some would say demonstrable, that the Intel processors which utilize the EM64T instruction set, are actually 32 bits internally, while merely emulating x86-64 in microcode, whereas the AMD64 processors are physically 64 bits internally.

That's the part that mainly concerns me. I'm assuming from your replies that Conroe is 64 bits internally?
 
Here is the best testing for 64bit performance I have seen so far:

http://techreport.com/etc/2006q2/woodcrest/index.x?pg=4

It is a Woodcrest against a Opteron. They mainly use 64bit programs to test on it. It doesn't really matter how the new Intel chips manage 64-bit programs, just how they perform in the end.

**Edit**

You have to remember Intel had to reverse engineer AMD64 in order to have it on their chips. Most of the time this isn't going to work as well as the original.
 
xFlankerx said:
I have a relatively simple question - Does the Conroe processor still emulate 64-bit capability like the Pentium 4s, or is it now a truly 64-bit processor like AMD's Athlon 64s?
I am sorry this is just fluff, Athlon 64's isn't any more of a native 64Bit processor then Pentium 4's are. You can't have a native X86-64 processor as the X86 architecture dates back to I dunno what 8 or 16Bit?

The only native 64Bit processor is the Itanium or most likely things in the Enterprise level.
 
coldpower27 said:
I am sorry this is just fluff, Athlon 64's isn't any more of a native 64Bit processor then Pentium 4's are. You can't have a native X86-64 processor as the X86 architecture dates back to I dunno what 8 or 16Bit?

The only native 64Bit processor is the Itanium or most likely things in the Enterprise level.

Err, Bzzt, Your Wrong, You lose. Internally the AMD64 has 64bit registers, and etc but they run in 32bit mode, I'm to tired and don't care too much about it right now to expalin it, but its basicly a native 64bit chip which was built on the x86 architexture and has 100% *native* backward compatablity with 32bit x86 (basicly it just turns off all the registers it isn't using) while the Intel is a reversed engineered(from AMD64) bolt on, its a 32bit procceser with a 64bit bolt on, in the end it doen;t mattter, no one cares, you know why because regardless of if its built in or bolted on, all that matters is how it performs, and atm the conore seems to be doing just that.

Chilly
 
xFlankerx said:
That's the part that mainly concerns me. I'm assuming from your replies that Conroe is 64 bits internally?
The P4 has 64-bit registers and a 64-bit instruction set. Nothing is emulated. The double pumped ALUs in the P4 are a bit odd though: in the Prescott with EM64T and later cores, the 32-bit ALUs are used to perform 64-bit integer functions. It doesn't really matter that it takes twice as many half cycles to compute a result, it's transparant to the instruction set and user.

If you're interested in how the Netburst double-pumped ALUs work, read the ars article: http://arstechnica.com/articles/paedia/cpu/p4andg4e2.ars/2 . The original Willamette/NW used 16-bit ALUs to perform 32-bit integer functions and the Prescott and later cores widened it to 32-bit. For that to be considered emulation, you would also have to call 32-bit integer instructions on the Willamette/NW "emulated" too. :rolleyes:

BTW, the "emulated in microcode" section in wikipedia is nonsense. Whoever wrote that has no clue where microcode is used in the P4.
 
Chilly said:
Err, Bzzt, Your Wrong, You lose. Internally the AMD64 has 64bit registers, and etc but they run in 32bit mode, I'm to tired and don't care too much about it right now to expalin it, but its basicly a native 64bit chip which was built on the x86 architexture and has 100% *native* backward compatablity with 32bit x86 (basicly it just turns off all the registers it isn't using) while the Intel is a reversed engineered(from AMD64) bolt on, its a 32bit procceser with a 64bit bolt on, in the end it doen;t mattter, no one cares, you know why because regardless of if its built in or bolted on, all that matters is how it performs, and atm the conore seems to be doing just that.

Chilly
Well considering you provided no proof I will just say same to you.

There is no such thing as a native 64Bit x86 processor the 64Bit intsturction set was added to the existing x86 architecture, nothing more. If you don't care why did you care enough to respond to my post.
 
In other words, they aren't true 64 bit processors and thus as a result they bottleneck themselves as they have to keep emulating code that they can't really process in its native mode.

Assuming Vista is the resource hog it is, we'll have to shift to 64 bit processes in order to obtain a larger addressing size (2^64 bytes). This will basically result in an internal memory bandwidth bottleneck in any EM64T processor as it has to keep switching between two instruction sets.

So this is incorrect?
 
Link.

Its a thread on another Forum. Skip to the bottom, its by Gaara. He's one of the smarter 'kids' on the Forum.
 
xFlankerx said:
Link.

Its a thread on another Forum. Skip to the bottom, its by Gaara. He's one of the smarter 'kids' on the Forum.
Unfortunatley that didn't help too much, I would need to see more of his dicusssion regarding specifically regarding AMD and Intel topics.

I usually can tell when to believe or not depending on the posters style, and the way they post.

From what I can gather, I would remain skeptical for now, unless he provides where he acquired his information from.
 
coldpower27 said:
Well considering you provided no proof I will just say same to you.

There is no such thing as a native 64Bit x86 processor the 64Bit intsturction set was added to the existing x86 architecture, nothing more. If you don't care why did you care enough to respond to my post.

Well, a 64-bit processor is more than just an instruction set. As the Athlon 64 can natively handle 64-bit code via its instruction set, it *is* a native 64-bit processor. It can also perform 32-bit operations with no loss of performance, as it is based upon the 32-bit x86 architecture (x86-32).

However, saying that the Athlon 64 and also the EMT64-supporting Intel processors are not "native" 64 bit processors is nonsense. They make use of 64-bit general operation registes, as well as 64-bit arithmetic, logical, memory-register and virtual addresses.

Remember, x86 originally began as a 16-bit architecture, although this is generally forgotten. The architecture was extended to a 32-bit system with the introduction of the 386. Now only recently, AMD extended it once again to a 64-bit architecture. It may be a relatively old architecture by some standards, but it *is* 64-bit now.
 
ToastMaster said:
Well, a 64-bit processor is more than just an instruction set. As the Athlon 64 can natively handle 64-bit code via its instruction set, it *is* a native 64-bit processor. It can also perform 32-bit operations with no loss of performance, as it is based upon the 32-bit x86 architecture (x86-32).

However, saying that the Athlon 64 and also the EMT64-supporting Intel processors are not "native" 64 bit processors is nonsense. They make use of 64-bit general operation registes, as well as 64-bit arithmetic, logical, memory-register and virtual addresses.

Remember, x86 originally began as a 16-bit architecture, although this is generally forgotten. The architecture was extended to a 32-bit system with the introduction of the 386. Now only recently, AMD extended it once again to a 64-bit architecture. It may be a relatively old architecture by some standards, but it *is* 64-bit now.
Well, I guess you and I have difference of what the term "native" defines. To me natively means this architecture started at 64Bit and went up from there, x86 didn't. I am most certainly not claiming that K8 with AMD64 or Pentium 4 with EM64T are emulation implementations either, they are processors that can 64 Bit instructions with either a gain or negligble loss in performance.
 
coldpower27 said:
Well, I guess you and I have difference of what the term "native" defines. To me natively means this architecture started at 64Bit and went up from there, x86 didn't. I am most certainly not claiming that K8 with AMD64 or Pentium 4 with EM64T are emulation implementations either, they are processors that can 64 Bit instructions with either a gain or negligble loss in performance.

To me, "native" means that a processor can run code without a performance penalty (such as how IA-64 cannot natively run 32-bit software).
 
coldpower27 said:
Well, I guess you and I have difference of what the term "native" defines. To me natively means this architecture started at 64Bit and went up from there, x86 didn't. I am most certainly not claiming that K8 with AMD64 or Pentium 4 with EM64T are emulation implementations either, they are processors that can 64 Bit instructions with either a gain or negligble loss in performance.
If I drop a V8 into my car, which was previously an I4, are you saying that my car isnt REALLLLY a V8 because, well, it started life with an I4?
That's what you are implying. Which makes very, very little sense.
Alphas were 64 bit years ago, btw.
 
eno-on said:
If I drop a V8 into my car, which was previously an I4, are you saying that my car isnt REALLLLY a V8 because, well, it started life with an I4?
That's what you are implying. Which makes very, very little sense.
Alphas were 64 bit years ago, btw.
Is that an engine or something? I am not familar with motor analogies sorry. I certainly didn't say it wasn't a 64Bit processor, it just isn't a native one by my definition. It makes perfect sense to me.

If you replace your L4 engine with V8 it becomes a car with a V8 engine, it just wasn't a native V8 engine car, this doens't mean it isn't a V8 engine car.
 
eno-on said:
If I drop a V8 into my car, which was previously an I4, are you saying that my car isnt REALLLLY a V8 because, well, it started life with an I4?
That's what you are implying. Which makes very, very little sense.
Alphas were 64 bit years ago, btw.

Seems like you posted to the wrong Guy!
 
Who cares native 64 bit or not, only performance counts. I have heard that Banias, Dothans and Yonahs will not run 64 bit Windows XP, and 64 bit Windows Vista and only Meroms will run on 64 bit OS. Will someone enlighten me, is that so?
 
Sam Ontario said:
Who cares native 64 bit or not, only performance counts. I have heard that Banias, Dothans and Yonahs will not run 64 bit Windows XP, and 64 bit Windows Vista and only Meroms will run on 64 bit OS. Will someone enlighten me, is that so?
That is correct Banias, Dothan and Yonah do not have EM64T, Merom is the first low power mobile from Intel that does.
 
xFlankerx said:
Link.

Its a thread on another Forum. Skip to the bottom, its by Gaara. He's one of the smarter 'kids' on the Forum.

"Smarter kids" is right, the guy is clueless. All control dataflow in the backend of modern processors is emulated with microcode, microcode performance is based purely on the availability of resources. And since when do people care about how the backend works anyways? That stuff is transparent for a reason. All this "native support" crap is just oboxious "purism" driven by ignorance.
 
^what he said^

processors take the complex x86 and now x64 instructions and decode them into micro-ops. This talk about "native" support is more driven by marketing than by fact. Also, this still gets by the fact that more or less no widely useddesktop application is 64bits to begin with. I see AMD talking about how Intel introduced DDR2, and now FB-DIMMS before they were able to provide an advantage, but AMD pretty much did the same thing with its its 64bit processor, it introduced it way before most people would be able to use it. All the talk about the 64bitness of AMD processors is more of a marketing thing than anytihng else. It pretty much the exact same as the whole netburst clockspeed deal. 64 is twice as big a number as 32, that must mean its better!
 
BrownTown said:
^what he said^

processors take the complex x86 and now x64 instructions and decode them into micro-ops. This talk about "native" support is more driven by marketing than by fact. Also, this still gets by the fact that more or less no widely useddesktop application is 64bits to begin with. I see AMD talking about how Intel introduced DDR2, and now FB-DIMMS before they were able to provide an advantage, but AMD pretty much did the same thing with its its 64bit processor, it introduced it way before most people would be able to use it. All the talk about the 64bitness of AMD processors is more of a marketing thing than anytihng else. It pretty much the exact same as the whole netburst clockspeed deal. 64 is twice as big a number as 32, that must mean its better!


I disagree with this on concept alone....

Unlike clockspeed, and ddr2, amd64 requires software support, which means hardware needs to exist..... If it wasnt for amd64 getting released when it did, we would still be years away from it getting implemented, let alone supported.
 
ToastMaster said:
To me, "native" means that a processor can run code without a performance penalty (such as how IA-64 cannot natively run 32-bit software).

Makes a lot of sense, unlike what coldpower was saying...
 
duby229 said:
I disagree with this on concept alone....

If it wasnt for Intel .... we would still be years away from it getting implemented, let alone supported.

Otherwise correct.
 
savantu said:
Otherwise correct.

I don't know...I mean sure, Intel really only implemented EM64T support because AMD made such a big deal out of it. But I seem to remember Windows XP 64-bit kept getting delayed and delayed and then once Intel had a compatible processor on the market, well hey, XP 64-bit is now available.
 
savantu said:
Otherwise correct.

You know that buzzer sound you here on game shows? It's hard to spell, but here goes nothing.....

ehhh wrong.....

If it was up to Intel, 64bit chips wouldnt exist.... Remember it was amd64 first. if it wasnt for htat Intel would never have followed suit, Microsoft would never have released a 64bit OS, and we wouldnt be looking into the prospect of 64bit games and applications for Vista in another year or two...
 
savantu said:
Otherwise correct.


Nah. 64bit linux distros and programs were out before 64bit Nocona.

And duby, they would exist. They would cost $3000 and be called Desktanium.
 
robberbaron said:
Nah. 64bit linux distros and programs were out before 64bit Nocona.

And duby, they would exist. They would cost $3000 and be called Desktanium.

Intel does a lot of work on the SW side of things be it Linux or Windows.Once Intel gets on the boat things start to roll.
 
robberbaron said:
Nah. 64bit linux distros and programs were out before 64bit Nocona.

And duby, they would exist. They would cost $3000 and be called Desktanium.

Well, sure.... I dont know if that prospect is any better though.
 
savantu said:
Otherwise correct.

I see this as both correct and incorrect.

Intel releasing 64-bit capable processors for the consumer market surely helped spur Microsoft into finishing and releasing Windows XP Professional 64-bit edition.

However, AMD began work on expanding the x86 architecture long before Intel did, which is why Intel itself admits that it, for the first time ever, adopted an adaption of the x86 architecture (vs. Intel having been the one who furthered the architecture in the past).

If everyone recalls, AMD first announced work on expanding it back in 1999, meaning they possibly began it earlier than this. Intel didn't implement EMT64 until Prescott in 2004 (obviously Intel had been working Prescott long before this, but it also means that AMD was at the very least 2-3 years ahead, given that Intel utilized AMD's modifications for EMT64). Of course, Nocona was the first Intel processor to actually have EMT64 activated.

Also, Windows XP Professional 64-bit edition had already been announced long before Intel announced EMT64, thus making your claim that Intel is largely responsible rather dubious. Did EMT64 help to further ahead the move to 64-bit? Ofcourse. But remember, Intel implemented EMT64 more due to the competitive pressure applied by AMD's Athlon 64/Opteron line, than it was simply from Intel wanting to "further" the market.

As Microsoft also had intended Vista to truly be their move to 64-bit as well, Intel would have had to have implemented sooner or later anyway. Thus, Intel helped to get the ball moving faster, but AMD is the company that actually put us on this path and got the train going. Don't let your obvious Intel bias keep you from atleast complementing AMD once and awhile - after all, had AMD not gone this route, there would have been *zero* reason for Intel to have moved ahead with the likes of implementing EMT64, developing Conroe, etc.
 
EDIT: ^^^ beat me to it.


The way I remember it, AMD releases AMD64, then MS decided to support it. They phased out Windows XP 64bit edition (that one was for IA64) and started work on Windows XP Pro x64 edition. When MS annouced they were going to support AMD64, Intel annouces EM64T.

Intel with their pants down all the way through that section of history. At least Intel catching AMD with their pants down now methinks. Dog eat dog.
 
savantu said:
Intel does a lot of work on the SW side of things be it Linux or Windows.Once Intel gets on the boat things start to roll.

Yes, because clearly Intel is the only driving force of the industry. :rolleyes:

Hmm, I look at Vista and many of its intended features, and it reminds me not of anything that is Intel related, but rather that of another company: Apple.

I look at Windows XP Professional 64-bit edition, and I think "That wouldn't likely have been started had AMD not released the Athlon 64/Opteron line."

Hell, I even see Conroe and say "It's about time Intel released something that made it competitive again to counter AMD's last few years of dominance."

A little Intel biased much savantu?

Hell, someone I know very well's husband works for Intel as an electrical engineer in the Chandler fab, and even he gives props to AMD and others for how they've forced Intel to adapt and reevaluate itself into wanting to help to innovate and be the leader once again.
 
ryan_975 said:
EDIT: ^^^ beat me to it.


The way I remember it, AMD releases AMD64, then MS decided to support it. They phased out Windows XP 64bit edition (that one was for IA64) and started work on Windows XP Pro x64 edition. When MS annouced they were going to support AMD64, Intel annouces EM64T.

Intel with their pants down all the way through that section of history. At least Intel catching AMD with their pants down now methinks. Dog eat dog.


Here's how I recall it:

-AMD anounces AMD64.

-MS is being sued on anti-trust issues. AMD supports MS.

-MS ultimately "rewards" AMD by announcing they'll develop and release a version of Windows XP that supports AMD64 (there is much commentary from around 2003 concerning AMD's support for MS and how MS responded in a friendly way).

-Intel continuously states that the consumer market does not need to move to a 64-bit architecture (a case that can still be argued somewhat today on many grounds)

-Athlon 64s and Opterons outperform Intel's processors upon launch, and many begin heaping praise on AMD.

-Online tech sites make much out of how games of the future will greatly make use of 64-bit, how AMD is leading, and how Intel is behind.

-Intel ultimately announces EMT64, which had been much rumored, saying the technology was in Prescott from the start but not enabled, and will be upon the release of Nocona.

-Intel's early EMT64 reviews show it to be a steaming pile of dong compared to AMD's (a problem Intel ultimately did fix).

<followed by more history up to the present day, but I don't to go on any further> :p

Anyway, the point is that AMD should be greatly appreciated for getting us to the point where we are today. I don't understand why people dislike AMD so much or don't want to give it its due. Some of the fanbo ism on both sides makes me almost as sick as seeing the most diehard of Mac fans go on and on about Windows.
 
I was just giving an abridged version. You just added on to what I said. Just to be clear though. I am in no way a !!!!!! of either AMD or Intel, they're both corporate giants that will rob consumers blind given half the chance. I just go with who's got the biggest bang for the buck.


EDIT: wow of all the things I've read on this site, that particular f word gets censored. lol. I always though it was the posters typing it taht way. Learn something new everyday.
 
Back
Top