Talk:EM64T

To David Gerrard. The "See Also: AMD64" line at the top of the introduction was put there to emphasize that the main technical article would be AMD64, and that EM64T would only be an article about the history of Intel's EM64T in relation to AMD64. So it was not superfluous, it was deliberate.

Also I don't believe the bottom paragraph linking to articles that said that Intel's Nocona has performance problems is something that belongs in an encyclopedia. First of all, as of this moment Intel has not released any hardware with EM64T in it yet, everything is still in pre-release. Secondly, performance problems in a particular instance of hardware are a fleeting incident in an architecture that is expected to be around over several generations.

--ykhan 16:58, 2004 May 2 (UTC)

Is there a reference for this last paragraph, that Intel 'copied' the technology from AMD. That is rubbish/hype and a contrast to earlier statements of the article. This is not a 'new' technology, its an extension which means the direction was already deturmined. When AMD64 was 'developed' there wasn't any 'latitude' its IA-32 x2 with a few other items added. Indeeded calling it a technology is a little far fetched.

Copying AMD64 technology

Is this really true? It makes the article sound really bias aganst Intel. Although I wouldnt be supprised if Intel did copy AMD64 technology but I havent seen any actual proof that they did. Performance issues are also a bias sounding thing, but we'll know when actual benchmarks are to be seen, unless they already exist and I havent gone over them yet.

Until the issue dealing with suposed copying technology is resolved and the performance issue of EM64T vs Rivals, the neutrality of this article should be disputed. Sorry.

---

Thank you much better.

Intel names projects after rivers, not counties.

The Yamhill and Clackamas references within Intel are named after the Yamhill River and Clackamas River--two rivers in Oregon--and not after the Oregon counties which mostly contain them. I'll correct the main page.

Regarding copying; Intel and AMD have been copying each others' instruction sets and such for years. Much of AMD's line is a clone of Intel's stuff (including some key enabling technologies licensed to AMD by Intel); to claim that Intel is now "copying" AMD64 is not fair comment--unless one has evidence that Intel is doing anything below board. Emulating/supporting an existing instruction set is neither illegal nor immoral in the world of CPU design.

--EngineerScotty 22:52, 2 September 2005 (UTC)

"to claim that Intel is now "copying" AMD64 is not fair comment" – Why not? They've been doing it for years, and it is not illegal nor immoral. It is a relationship much worth noting, however.

More interesting, though, is the question how close is the EM64T instruction set architecture to that of AMD64? The article should say, but doesn't, only "See the AMD64 article for architectural details" suggesting they are identical. Are they? -R. S. Shaw 04:34, 6 September 2005 (UTC)

There is nothing wrong with that statement and it is totally unbiased, it's just the nature of AMD and Intel's cross-development contract, they both share all technologies pertaining to the x86 architecture. Maybe you just don't like it because this is the first time it's Intel copying AMD's technology and not the other way around. AMD developed the AMD64 extention to the x86 architecture and Intel copied it as EM64T (as well as NX bit, which I know was already around in the 80286+ in Paged Mode, but no one used Paged Addressing Environment as it was recognized as obsolete, it was AMD who added it to Linear Addressing Mode), just like AMD copied the entire x86 architecture from Intel (just to put it in to perspective, respectively they both did immense work adding to the archaic architecture). Also EM64T is largely the same thing as AMD64 (identical) except for maybe a few changes to make it fit into hyperthreading and dual-core technology better for Intel's plans, either way it's 100% with AMD64 compiled code and is recognized as the same thing as AMD64 in most CPU-ID programs (such a CPU-Z). -Xero.03 13:31, 30 September 2005 (UTC)

who was the 1st ?

http://www.theinquirer.net/?article=20072

Quite strange saying. Intel claimed that AMD had stolen most part of AMD64 form them :)

The 'claim' is quite vague. The Inquirer says:

According to Curry, Intel's "competitor" - that's AMD of course, took advantage of the work it had done. He said that the competitor announced its move into the 64-32 arena largely based on the work Intel had done.

Undoubtedly Intel worked on 64-bit extensions to x86 (as did AMD, and anyone interested would). Perhaps Intel researchers published some papers on the subject. The basic idea of 64-bit extensions is obvious; the details can differ, but are substantially constrained by compatibility. There's no claim here that there was an Intel design that was secret and was stolen. I wonder if this is a case of decomposing sour grapes emitting hot air. -R. S. Shaw 22:18, 18 November 2005 (UTC)

CMPXCHG16B

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

This statement is true but misleading: the double-width compare-and-swap is primarily used in Lock-free and wait-free algorithms. —The preceding unsigned comment was added by 81.19.78.190 (talk • contribs) 16:40, December 16, 2005 (UTC)

I don't know if I'd say it's misleading; it is accurate, it just doesn't mention the other possible use you've defined above. If you want to reword it, feel free. =) —Locke Cole 16:44, 16 December 2005 (UTC)

MONITOR/MWAIT

I'd like a source for this latest addition (especially the part claiming it's only useful for hyperthreaded processors). Given the technical definition of these instructions from Intel's own manuals, these would seem to be useful even in multi-core processors (not just hyperthreaded/SMT processors). If there's no verifiable source (or no objection) in a few days, I'll likely remove the passage. —Locke Cole • t • c 07:55, 2 January 2006 (UTC)

OK, but understand that this demand of yours is rude and irritating. It's something you should reserve for when you have consensus that the text is wrong.

The instructions are not quite 100% useless on plain SMP and dual-core. Having them is nice, and you might as well take advantage of that, but it doesn't really matter.

As evidence, see the linux-kernel mailing list (google site:lkml.org mwait) and the chunk of Linux kernel source code which I quote below:

arch/i386/kernel/process.c-276-static int __init idle_setup (char *str)
arch/i386/kernel/process.c-277-{
arch/i386/kernel/process.c-278- if (!strncmp(str, "poll", 4)) {
arch/i386/kernel/process.c-279-         printk("using polling idle threads.\n");
arch/i386/kernel/process.c-280-         pm_idle = poll_idle;
arch/i386/kernel/process.c-281-#ifdef CONFIG_X86_SMP
arch/i386/kernel/process.c-282-         if (smp_num_siblings > 1)
arch/i386/kernel/process.c-283-                 printk("WARNING: polling idle and HT enabled, performance may degrade.\n");
arch/i386/kernel/process.c-284-#endif
arch/i386/kernel/process.c-285- } else if (!strncmp(str, "halt", 4)) {
arch/i386/kernel/process.c-286-         printk("using halt in idle threads.\n");
arch/i386/kernel/process.c-287-         pm_idle = default_idle;
arch/i386/kernel/process.c-288- }

Note the explicit check for hyperthreading (smp_num_siblings > 1) and the mention of hyperthreading (HT) in the warning message. This warning will not print on a non-hyperthread system. The warning is used because having one side of a hyperthreaded CPU poll memory will cause the other side to get fewer cycles.

This old discussion may be of interest: http://lkml.org/lkml/2004/9/12/41

24.110.60.225 AlbertCahalan 03:33, 5 January 2006 (UTC)

I see that the SSE3 page already provides a reference. I hope you (Locke Cole) don't make such burdensome and abusive demands in the future, to me or to any other person editing wikipedia.

24.110.60.225 AlbertCahalan 03:55, 5 January 2006 (UTC)

There's nothing burdensome about my request, it is in fact one of the core philosophies of Wikipedia: Verifiability. (Which is in turn backed up by another philosophy: No original research). I'll look into the information you've presented, but I'll say up front I'm not impressed with the age of the research you cite (all circa 2004 it seems, before dual core processors were a consideration). Thanks for responding though, I'll get back to you on my thoughts. —Locke Cole • t • c 04:12, 5 January 2006 (UTC)

The chunk of code is from the linux-2.6.13.4 kernel, which is quite recent. I've only ever seen WP:V used abusively. You'd do well to forget that it exists, lest it tempt you to treat others as you surely would rather not be treated. See The Golden Rule. Alternately, you could go threaten to delete the whole Serine article for not providing references, hmmm? Most articles are like that, for reasons that should be obvious and acceptable. Have you provided references for all your wikipedia edits? Would you like people threatening to delete them? 24.110.60.225 AlbertCahalan 04:38, 5 January 2006 (UTC)

Next time you edit, you might consider looking just above the edit summary input box, it says, and I quote, "Content must not violate any copyright and must be verifiable. Your contributions will be licensed under the GFDL.". No, I don't source everything I ever add to Wikipedia, but then I don't add things I've made up myself (I usually have a source I'm working from that backs up what I'm writing). If I didn't have a source, it would be original research and unverifiable. That's bad for Wikipedia. Now please, be civil, as I was in my original request for some references supporting the passage, and stop acting like I've harassed you in some way by discussing this and not simply removing it out of hand (as I could have done, had I been so inclined). —Locke Cole • t • c 05:38, 5 January 2006 (UTC)

Please take a deep breath, 24.110.60.225, and calm down. If you look again at LockeCole's original post, there was nothing rude there. He did not demand sources, just asked about the statement. In fact he was quite considerate in starting a discussion here rather than just deleting the text that seemed incorrect to him. Comments on article text which you may have written is not an attack. -R. S. Shaw 06:40, 5 January 2006 (UTC)

He could have simply said "Why is monitor/mwait mainly a hyperthread thing?" instead of bringing out the heavy weaponry. Once you mention WP:V, you've basically accused someone of writing a pile of bullshit. In this case, there was a findable reference. I know plenty of things that I've learned over the years, via college textbooks for example, that are possible but very difficult to verify. It's not right to needlessly ask people to dig up ISDN numbers of books that got discarded years prior, especially since the accuser is very unlikely to go buy or borrow the reference. AlbertCahalan 07:12, 5 January 2006 (UTC)

WP:V is not "heavy weaponry". Until you told me the anon was you (on my WP:RFA) I had no idea if this anon was simply new (and might like to know in advance why I was asking for a source for this bit of information), or was trying to slip in POV to downplay MONITOR/MWAIT (in which case, WP:V would probably force the individual to rethink adding unverifiable POV to an article). I do not consider mentioning WP:V to be akin to accusing someone of writing a "pile of bullshit". And neither do a lot of other editors on Wikipedia. Being verifiable is important for Wikipedia, and as policy, it has been accepted by a consensus of editors. The same holds true for WP:NOR and WP:NPOV. I consider asking for verification to be "right", and I do not believe my request was "needless". Please be more considerate of Wikipedia policy in the future, and don't automatically assume bad faith on the part of someone requesting verification. —Locke Cole • t • c 07:41, 5 January 2006 (UTC)

As a follow-up, I've done a very limited bit of research into this, and while I haven't come across anything discounting the idea that MONITOR/MWAIT are hyperthreading specific, I also haven't come up with much supporting it (beyond the LKML entry above, which may or may not be a reliable source). In any event, I came across this (pdf) which states that MONITOR/MWAIT will be implemented in AMD processors in 2007. If it's only relevant to hyperthreading implementations, I wonder why they'd announce planned support. I'll look into this more later as time allows, I just wanted to give an update on my research. —Locke Cole • t • c 23:34, 9 January 2006 (UTC)

Invented history,inaccuracies and bias

This article has a clear bias towards AMD and the originator will not allow changes to make it accurate. He does not know the real history here and will not allow it to be changed to reflect that and is therefore a fairly useless article as it reflects how he wishes history to be written. For example, what he doesn't seem to know or is choosing to ignore is that Intel developed the 64 bit extensions back in 97/98 and as part of a deal with Microsoft around the Itanium port of Windows Intel agreed that MS could disclose the specifications for said extensions to AMD. This story is far more complex than the author knows and his bias is evident.

—The preceding unsigned comment was added by 143.183.121.3 (talk • contribs) 01:35, 15 March 2006 (UTC)

You seem to under some misapprehensions, 143.183.121.3. This article was originated by User:Bsoft, but he hasn't touched it since March 2004. This article wasn't written by "the author"; it has been written by many (>30) different editors. Your (one) contribution was reverted by just one editor, who doesn't appear to have contributed any of the text to the article.

As to the reverted edit you had added, there were a couple of problems with it. One is that it deleted the reference to the detail of the EM64T architecture. Another is that the added text saying the "architecture goes back to the mid '90's starting with Intel's decision to support two 64 bit architectures" just hangs in midair. There need to be sources showing this to be case, and whatever the mid-90's development was would need to be related to what turned out to be the actual released EM64T architecture.

The article may indeed have a bias, and that should be worked out of it. The active editors should try to come to a consensus. Perhaps you could start this by pointing out here on the talk page some of the biased items you see needing revision. -R. S. Shaw 04:26, 15 March 2006 (UTC)

I don't know if you're targeting me, we're all authors around here. As to your claim that Intel developed the 64-bit extensions first, do you have any source for this information? It's the first I've heard of anything like it. If it is true, then it's not myself or others here who are covering it up. In all the articles I've read on the AMD64 architecture and the Opteron and Athlon64 processors, it's always credited to AMD. I'm simply upholding what I believe to be widely held facts. So do you have any proof of your claims? Imroy 04:34, 15 March 2006 (UTC)

It's been over 24 hours now and no answer from 143.183.121.3, so I've removed his disputed tag from the top of the article. I've only just now run a whois lookup - the IP belongs to Intel! One wonders what his motives were, and if the story had any truth to it. I mean, Intel and AMD have had some licensing deals in the past, that was how the Am386 came about. But that was a long time ago and I just cannot see this happening in the recent climate of competitiveness. And why on earth would Intel decide to run with two completely incompatible 64-bit architectures? I find that his claimed version of events just doesn't make sense. Imroy 06:17, 16 March 2006 (UTC)

There's no evidence revealed here to support 143.183.121.3's scenario, and so nothing should be in the article about it, but the scenario is somewhat plausible to my way of thinking. Almost certainly Intel in the 90's studied how 64-bit addressing could be integrated into the IA-32 architecture; it's an obvious and important area, and Intel could afford the resources for basic study and architecture development. It's also plausible that Intel had a deal about porting Windows to Itanium. Maybe MS wanted a 64-bit platform for development other than Itanium (availability maybe a problem), and Intel might have provided such a thing (doubtful). Or MS may have known about Intel's IA-32-64 architecture, and wanted to know all details to make the 64-bit Windows suitable for it as well as for Itanium, and hence the disclosure, and MS might have insisted on disclosure to AMD (to maintain its enviable position in hardware vs software revenues in the industry).

Intel did not "run with" two 64-bit architectures until forced to. Intel clearly put all its external support and the bulk of its internal 64-bit resources into Itanium ("IA-64") for a decade or more. It could be a big win to Intel if it could make Itanium a success in applications needing 64-bit addressing (which eventually would become most of the market). This is because it would have a monopoly on Itanium machines with good barriers protecting that monopoly, very unlike the x86 arena. Yet it would be only prudent for Intel to protect itself against AMD (or ?) successfully launching upward compatible 64-bit extensions to x86, a not unreasonable possibility. Hence, Intel would need to have something like EM64T simmering on the back burner, all the while keeping that very, very quiet (to avoid impact to Itanium). Intel's long denial of Yamhill's existence is consistent with that. Anyway, this is all speculation until a reliable tell-all appears to confirm or refute it, which may not be for a decade or two. -R. S. Shaw 20:40, 16 March 2006 (UTC)

Concerning your idea that "Maybe MS wanted a 64-bit platform for development other than Itanium"; has everyone forgotten the Alpha already? It was the most popular and successful of the non-x86 ports of Windows NT and I believe MS even threatened Intel with pushing the Alpha in order to get something out of them. There was a MIPS port and even a PowerPC port, but they didn't go anywhere. So I don't agree with the idea that MS wanted another 64-bit platform when several were already available. However I do agree a company the size of Intel could (and should) have done some sort of analysis and research on the idea of extending x86 to 64 bits. We just have to figure how, why, and (most importantly) if Intel transferred a 64-bit x86 ISA to AMD. Imroy 01:18, 17 March 2006 (UTC)

It's a damn shame

Articles like this shouldn't be put in here :D Imagine if someone who is not familiar with either Intel or AMD reading this. Reading between the lines is not fun here. It's as chronical Intel fall down article as any AMD fan would write. What reverse ingeneering ? x86 is an Intel architecture and AMD were not invited to it. But they did copy as much as they can and made cpus on another's back. AMD always tried and tried and tried to achieve something here. First it was the Big Fat cpu Copy. Of course it sucked. Then it was fabric cpu overcloack, which did not suck that much, but smelled and caused overheating insted (even now you can see explosion of a modern AMD cpu at google videos, it took a part of the mainboard along with itself): by the time when Intel made 2.4 GHz P4 which could be o/cloacked up to 2.8 or 3.2 GHz (I don't remember right now) without even change of the core voltage, AMD fans were experiencing the 1.4 GHz AMD cpus fabricaly o/cloacked to 2.0 GHz (and running hot as hell). Then of course came along the time for at-home 64bit cpus. Alright. Intel showed the world a brand new 64 bit technology, made from scratch. They called it Itanium, IA-64. What AMD did then ? Hehe, no, they didn't copy. They just kept the good old Intel x86 arch but extending it with 64 registers, which meant not only 64 bit computation and almost no effort what-so-ever (again) (and comparing to the Itanium creation) but also the possibility of performing these good old Intel x86 instructions, so much used in the world at the time. While Intel of course faced the need of software for their platform. Well, what can I say ? Yes, for a first time Intel had to face with their actions all the **** AMD slowly created as the years passed by and make their own 64 extension of the x86 arch. Did they reverse ingeneered it ? Well how can you reverse ingeneer something you made 15 years ago, in the first place, from someone who had stolen it 10 years ago.—Preceding unsigned comment added by Butterfly collector (talk • contribs) 23:17, July 8, 2006