Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature currently requires accessing the site using the built-in Safari browser.
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.
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.
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?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?
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.
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.xFlankerx said:That's the part that mainly concerns me. I'm assuming from your replies that Conroe is 64 bits internally?
Well considering you provided no proof I will just say same to you.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
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.
It seems like it's an opinion, I would need the actual source and who wrote it to know more.xFlankerx said:So this is incorrect?
Unfortunatley that didn't help too much, I would need to see more of his dicusssion regarding specifically regarding AMD and Intel topics.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.
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, 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.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.
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?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.
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.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.
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.
That is correct Banias, Dothan and Yonah do not have EM64T, Merom is the first low power mobile from Intel that does.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?
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.
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!
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).
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.
savantu said:Otherwise correct.
savantu said:Otherwise correct.
savantu said:Otherwise correct.
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.
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.
duby229 said:Well, sure.... I dont know if that prospect is any better though.
savantu said:Otherwise correct.
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.
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.