Talk:X86-64

From Wikipedia, the free encyclopedia

 This article is within the scope of Computing WikiProject, an attempt to build a comprehensive and detailed guide to computers and computing. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion.
??? This article has not yet received a rating on the quality scale.
High This article has been rated as High-importance on the importance scale

Contents

[edit] "To Clone"

The best term to describe what happened is: "Intel has cloned AMD64 under the name Intel 64". In the early 80s, PCs were referred to as "IBM PC clones". Cloning is taking a technology (e.g. instruction set) and re-implementing it from scratch. I have taken the liberty to reword the introductory paragraph accordingly, because the term that was used before ("Intel has also adopted AMD64 under the name Intel 64") appeared too weak IMHO. Comments ? -- R. Duxx 67.53.116.122 03:23, 8 September 2007 (UTC)


I agree about the terminology. it is the proper term for the actions that were taken. 68.42.67.162 05:31, 26 October 2007 (UTC)

[edit] Error Corrected

Please note: This information was incorrect: "traditionally, operating systems take one half of the address space for themselves (usually the higher half, named kernel space) and leave the other to applications (user space)". It's highly unusual to put the kernel at the top. Usually it's at the bottom, below the program code and data segments, and the stack is usually at the top.

I don't know how Unix does it (except that some variants use an entire separate process for the kernel) but the description was correct for the NT family. By the way, how does your idea fit with the fact that there are multiple user address spaces (one per process), multiple stacks (one per thread) within each, multiple heaps per process, a kernel mode stack in kernel space for every thread in the system in addition to its user mode stack (the k-mode stacks are in the kernel space), and "data segments" haven't existed since NT 3.1? Well, they exist, but they have base address 0 and size (size of VAS), just like the code and stack segments. Things are a bit more complicated than you represent and the notion of basing "the" stack at FFF...FFF so it "won't grow into other things" is, well, just not applicable. Jeh 08:16, 21 April 2007 (UTC)
Most operating systems I know of put the kernel at the top of the virtual address space on x86 platforms, usually splitting the virtual address space 3:1 or 2:2 with the kernel getting the top half. It is theoretically possible to put the kernel in a separate address space (as is done on SPARC processors, for example) but the cost of doing so is much greater than the benefits would warrant. The standard Unix process layout puts the text segment at the bottom of the address space (but a little bit above address 0), the data and bss segments above that, mapped files above that, and then stack at the top of user space (growing downward). 18.26.0.5 20:09, 12 June 2007 (UTC)
Well, there you go. :) Nevertheless, putting "stack" at the top of user space doesn't prevent "it" from growing into anything, since each thread in the process needs its own stack. You can't put more than one of them at the top! Jeh 20:07, 13 June 2007 (UTC)

[edit] Merging AMD64, EM64T, and x64

After weeks of discussion on the Talk:X64 page, there was little opposition to merging the three articles. The biggest debate was about what the name should be: AMD64, EM64T, and x64 or something else, namely x86-64. --Charles Gaudette 21:47, 18 September 2006 (UTC)

IMHO it should be x86-64 as it is the most general term for the architecture. x64=> windows AMD64=>amd processors EM64T=>Intel processors. 68.42.67.162 05:33, 26 October 2007 (UTC)

[edit] Move from AMD64

Woah. Was there a consensus to rename this page? I for one oppose this. AMD64 is the name of the architecture, like IA-32 is the name of an architecture. AMD64 is in wide use by many linux distributions, BSD systems, Microsoft, etc, to refer to this architecture. We need a vote or a consensus on such a drastic change that seems to take neutrality overboard to the point of changing the meanings of words. samrolken 07:25, 22 September 2006 (UTC)

Are you saying you have read the comment above and the Talk:x64 discussions? And are still unhappy? --Charles Gaudette 18:56, 22 September 2006 (UTC)

Donald: AMD64 incorporates most if not all x86 features, therefore x86-64 seems a good choice. In the intro we could mention amd64 as the first name, created by AMD. —Preceding unsigned comment added by Donald j axel (talk • contribs) 08:54, 16 April 2008 (UTC)

[edit] Paging hierarchy size

I've just replaced a some text that misleadingly stated that a full 64-bit PML4 would be 256 MiB long. In fact, the size is right for the PML4, but I think a better impression would be given if the size of the whole page mapping hierarchy is shown. These are my results for the current 48-bit hierarchy:

  • One PT: 512 entries x 8 bytes = 4096 bytes
  • One PD: 512 entries x (8 bytes + size of the associated PT) = 2101248 bytes = 2052 KiB
  • One PDPT: 512 entries x (8 bytes + size of the associated PD) = 1075843072 bytes = 1026 MiB
  • The PML4: 512 entries x (8 bytes + size of the associated PDPT) = 550831656960 = 513 GiB

Which yields about 0.2% of the 256 TiB space. Phew! Anyone wants to try calculating this for a possible 64-bit scheme? Habbit 09:22, 9 October 2006 (UTC)

Not really. The size of the PML4 was enough to scare me. :)
By the way, do you have a source for this change:
"In implementations supporting larger virtual addresses, this latter table would either grow to accomodate sufficient entries to describe the entire address range, up to a theoretical maximum of 33,554,432 entries for a 64-bit implementation, or be overranked by a new mapping level, such as a PML5"
The AMD docs suggest PML4 will be extended, specifically this one, on page 133:
"Note: The sizes of the sign extension and the PML4 fields depend on the number of virtual address bits supported by the implementation."
Now obviously as there is no implementation with more than 48 bits available yet this is still subject to change, but I think that's a pretty clear statement that the PML4 will be expanded in such cases. Unless another source contradicts it, in which case we'll just have to wait and see... JulesH 15:07, 14 October 2006 (UTC)
I don't think that means the PML4 is to be expanded on >48b implementations. It sounds like "don't take the 48 bits for granted, could be less in some sadistic but still amd64-compliant platforms". Think about an expanded PML4 and you'll see an unmanageable 32 million entry behemoth. Habbit 18:45, 14 October 2006 (UTC)
Not that it really matters now, but I think my figures were wrong because IIRC each descriptor entry is 16 bytes long, not 8, in amd64. Which means all figures must double: the whole 48-bit paging scheme would eat up 1 TiB of memory! Can somebody please confirm this? My final sum is 240+231+222+213, or 1 101 663 313 920 bytes. Habbit 01:19, 2 April 2007 (UTC)

[edit] x86-64 or AMD64 ??

Why the name has been changed to x86-64 ??

AMD stated and offically declared the rename of technology from x86-64 to AMD64...

the title for this Article must be AMD64, and any one enters x86-64 must be redirected to AMD64

The name of the page was changed to x86-64 because the page covers both AMD's implementation of the instruction set, which they now call AMD64, and Intel's implementation, which they've called, at various times, IA-32e, EM64T, and Intel64. The name x86-64 is a vendor-neutral way of referring to the instruction set, and not one specific to particular OSes, as x64 is. See Talk:x64 for the full discussion on the name change.
Given that AMD aren't the only company implementing the instruction set, the fact that they now call it AMD64 to promote their invention of it does not in any way impose any sort of requirement that the article be called AMD64, so, no, the title of this article is not required to be AMD64. Guy Harris 11:55, 14 November 2006 (UTC)
The name of the architecture is AMD64 in the same way that the name of the architecture it expands upon is i386 (i for Intel). When a company develops something, they get to name it - the fact that Intel calls their implementation of the instruction set something else is amusing, but it doesn't change the fact that the proper name to use for the architecture / instruction set in an encyclopedic work is AMD64. Chandon 02:05, 16 November 2006 (UTC)
In fact, it referred to in most literature as x86_64, not x86-64, but maybe Wikipedia conventions do not allow such a name ? If they do, a redirect from x86_64 to x86-64 could be of help for some people. 81.65.26.7 00:47, 14 December 2006 (UTC)
Did you try it? It's there (since 2004, apparently). Because of the way Wikipedia names are mapped, it's called "x86 64", but if you type in x86_64, it does the expected thing. --NapoliRoma 01:59, 14 December 2006 (UTC)
The use of the underscore instead of a hyphen (ie. x86_64 versus x86-64) is purely due to the syntactic limitations of identifiers in the C programming language and/or C preprocessor. The main places where you'll find "x86_64" are in the Linux kernel and the GNU Compiler Collection. Letdorf 11:59, 23 May 2007 (UTC).

Why is this page called x86_64 and x86 called IA-32? Seems to be a bias on wikipedia —Preceding unsigned comment added by 74.73.6.35 (talk) 07:40, 2 June 2008 (UTC)

x86 != IA32 and if you type x86 into the box you'll end up at a suitable article for that term. IA32 could have been called i386, but that's hardly vendor neutral and would also be confused with the i386 CPU.--Anss123 (talk) 07:49, 2 June 2008 (UTC)

[edit] History of AMD64

It would be nice to have a history subsection of the AMD64 section. When was the technology announced for the first time? When was the first emulator available? when was the first piece of hardware available? --Jarl Friis 07:45, 26 January 2007 (UTC)

[edit] Date or year of initial linux support.

Since Linux was the first OS to run x86-64 in long mode, it would be very relevant to know when that happend, can someone tell. When and which was the first linux distribution to officially release a version with x86-64 support? I think it was SuSE, but I am not sure. --Jarl Friis 07:50, 26 January 2007 (UTC)

x86-64 support was merged into the development kernel at 2.5.5 (released 20th Feb 2002, see Changelog-2.5.5). A beta version of x86-64 SuSE was made available a few months before the actual release of AMD's first x86-64 Opterons ("Hammer") in April 2003 as per [1]. Debian merged x86-64 to Sid in mid-2004 and there was an "unofficial" x86-64 Sarge release in 2005, but as of yet, no official version (pending the release of Etch). Redhat made an x86_64 release sometime after SuSE. Andrew Rodland 23:40, 28 February 2007 (UTC)


I'm fairly sure that gentoo was the first distrobution to release 64bit support in a stable release. I sadly cannot find the date or the page i originally read that on Gaurdro 05:40, 26 October 2007 (UTC)

[edit] neutrality tag on differences section

It seems to me that the differences are consistently worded in a non-neutral way. The first few are worded like 'intel does not support', but then the later ones are worded as 'intel does support'. It seems like they should be parallel in their wording. Intel does not do blah, AMD does not do blah. Jabencarsey 21:05, 16 April 2007 (UTC)

I can at this point only find one example of what you're saying:
"Intel 64 supports the MONITOR and MWAIT instructions, used by operating systems to better deal with Hyper-threading."
That line could perhaps be worded "AMD64 lacks the MONITOR and WAIT instructions, ..." for consistency with some of the Intel 64 differences, but otherwise I can't see much that feels wrong there myself. Maybe some things have been updated since you made your comment though. Otherwise, if you're still seeing problems, just be bold and try to make them as you feel more neutral. As long as the sentence is telling the same thing afterwards, it's edits of low "risk" of upsetting people anyway. ;) -- Northgrove 23:10, 29 April 2007 (UTC)


[edit] x87 / SSE2

According to the Intel® 64 and IA-32 Architectures Software Developer’s Manual, x87 is supported in long mode (not just compatibility mode). Could someone please provide a link for the assertion that Win XP x64 won't allow x87 instructions in long mode? Additionally, SSE2 is (strictly speaking) not a replacement for x87 because some math capabilities are only exposed through x87. For example, there is no SSE2 equivalent for FCOS / FSIN - OTOH you have addsd (SSE2) that does the same thing as fadd (x87). Commutator 23:38, 25 May 2007 (UTC)

[edit] x86_64 FS and GS registers

When I tagged the "Removal of older features" paragraph as needing a citation, my intention was to bring attention to the "fact" about AMD keeping the FS and GS registers in their x86 64 bits design for compatibility with Windows. I couldn't find any mention of this in internet, and neither of Jeh's statement in the changelog of the page ("they were retained at the request of the Windows kernel team"). What I did find somewhat contradicts what he said (taken from http://msdn.microsoft.com/msdnmag/issues/06/05/x64/default.aspx , emphasis mine): "In x86 versions of Windows, the FS register is used to point at per-thread memory areas, including the "last error" and Thread Local Storage (GetLastError and TlsGetValue, respectively). On x64 versions of Windows, the FS register has been replaced by the GS register". So, I still think that the x86_64 article needs some references regarding this information. Azrael81 14:42, 31 May 2007 (UTC)

The debugger tells me that both I and the MSDN article are incorrect; FS (or rather the segment descriptor selected by the contents of FS) still points to the TIB under x64 in long mode; but GS seems to contain the same selector value as DS, hence base address 0. "Hmmm." As for "retained for compatibility with Windows," I got this information originally in private conversation with one of the kernel team, one who was in a position to know -- but I don't have a reference wiki can point to. I'll see if I can find one. Jeh 17:14, 31 May 2007 (UTC)
Since original research is not welcome in wikipedia, and there's still no reference for the "compatibility with Windows" bit, I'm going to remove that piece of information from the article. Azrael81 12:50, 16 August 2007 (UTC)
Since the F segment register and descriptor most certainly are there, and are used on x64 as they were under x86 Windows, I am restoring the easily-verifiable information about the F segment. As you had it the item is incomplete at best: the segmenting mechanism is NOT completely gone in long mode. Jeh 17:43, 30 August 2007 (UTC)
I put the original item back, with a reference to the AMD64 documentation. If the problem is with the "compatibility with Windows" part, then just remove that - and remove the note about the FS and GS registers from the section on Windows support, which also mentions this; the FS and GS registers (and, it appears from that section, the CS register) do have some effect, so we should at least mention that. Guy Harris 19:29, 30 August 2007 (UTC)

[edit] Special handling of Category:Advanced Micro Devices products

I've done something that User:Intgr points out is a little unusual: rather than adding the above category link directly to this page, I've added it to the AMD64 redirect page instead. The reason I've done this is so that on the category page itself, it will appear as "AMD64" rather than "X86-64", since the AMD product is indeed named "AMD64". There is no other way I'm aware of to make this happen (category pipes only change sort order, not the name that appears), although there's apparently a request pending for such a feature.--NapoliRoma 17:41, 2 June 2007 (UTC)

[edit] Windows Vista x64 build number

"... Windows Vista x64 was released in January 2007. Internally they are actually the same build (5.2.3790.1830 SP1)" - isn't Vista build number different? --0xF 15:57, 10 July 2007 (UTC)

[edit] "IA64t"

In today's edits, I removed a reference to Intel 64 once being known as "IA64t". I found very few references at all to this term (or to "IA-64t"), and many of the ones I did find seemed to equivalence it to IA-64 rather than Intel 64, including in a couple of 1998 speeches by Intel execs, which would have predated AMD's x86-64 announcement. (These latter may also be a mistranscription of IA-64™, since one of them also refs "MercedT".) If anyone has backup for this term ever being used officially by Intel to refer to x86-64, please update the article.--NapoliRoma 14:45, 3 August 2007 (UTC)

[edit] Fair use rationale for Image:AMD64 Logo.svg

Image:AMD64 Logo.svg is being used on this article. I notice the image page specifies that the image is being used under fair use but there is no explanation or rationale as to why its use in this Wikipedia article constitutes fair use. In addition to the boilerplate fair use template, you must also write out on the image description page a specific explanation or rationale for why using this image in each article is consistent with fair use.

Please go to the image description page and edit it to include a fair use rationale. Using one of the templates at Wikipedia:Fair use rationale guideline is an easy way to insure that your image is in compliance with Wikipedia policy, but remember that you must complete the template. Do not simply insert a blank template on an image page.

If there is other fair use media, consider checking that you have specified the fair use rationale on the other images used on this page. Note that any fair use images uploaded after 4 May, 2006, and lacking such an explanation will be deleted one week after they have been uploaded, as described on criteria for speedy deletion. If you have any questions please ask them at the Media copyright questions page. Thank you.

BetacommandBot 04:52, 16 September 2007 (UTC)

[edit] Stupid question

Is there any chance to run a 64-bit program on a 64-bit (AMD64) machine with a 32-bit version of Windows? —Preceding unsigned comment added by 212.149.216.233 (talk) 14:35, 14 November 2007 (UTC)

Yes, with vmWare you can run a 64-bit OS, and with that 64-bit apps, on top of the 32-bit Windows.--Anss123 17:36, 14 November 2007 (UTC)
Good to know. Thank you. --212.149.216.233 18:51, 14 November 2007 (UTC)
Wikipedia's not a support forum, so questions such as this aren't what talk pages are for (they're for discussing the corresponding article, not for general questions about what the article describes).
However, I'll respond anyway, as I'm not sure the answer to your question is "yes". VMware doesn't seem to have a clear answer to the question. Hardware and Firmware Requirements for 64-Bit Guest Operating Systems says, not surprisingly to me, that "Workstation and VMware Server require a 64-bit CPU to run a 64-bit guest operating system", noting, correctly, that "While it is theoretically possible to emulate a 64-bit instruction set on 32-bit hardware, doing so most likely results in unacceptable performance degradation." However, the "Supported and Unsupported Guest Operating Systems" page of the Guest Operating System Installation Guide says "To run a 64-bit guest operating system on 32-bit Intel hardware with VT support, you must enable VT on the host machine BIOS." - and then points you to Hardware and Firmware Requirements for 64-Bit Guest Operating Systems which, as noted, says you can't run a 64-bit guest OS on 32-bit processors.
So I suspect the answer to your question is "no"; unless somebody's successfully run a 64-bit guest on a machine with a 32-bit processor, I'll continue to have that suspicion. (Running a 64-bit guest on a machine with a 64-bit processor running a 32-bit OS might be possible. I'm doing so on Mac OS X v10.4, but that OS does support some 64-bit userland code, so the actual virtual machine code in VMware Fusion might be running in 64-bit mode.) Guy Harris 19:19, 14 November 2007 (UTC)
Dunno about various VMware versions, but I ran Vista x64 on top of XP32 to test my apps. It worked fine then, although I was using a free beta version of VMware. But it's 'possible'. Too bad Vista x64 doesn't support the surprisingly many 16-bit apps I still use. sigh. --Anss123 20:15, 14 November 2007 (UTC)
Did the machine running 32-bit XP have a 32-bit processor or a 64-bit processor? (I missed the "64-bit (AMD64) machine" in the original question; given that, the answer to that question is probably "yes", modulo the constraints mentioned in the two VMware documents I cited.) Guy Harris 20:32, 14 November 2007 (UTC)
Oh, the CPU was 64-bit. I think qemu can run 64-bit on a 32-bit CPU.--Anss123 20:42, 14 November 2007 (UTC)

[edit] Incorrect statement about cmpxchg16b

Article says:

Without CMPXCHG16B the only way to perform such an operation is by using a critical section.

This is not true. There are lock-free algorithms to do it. For example this paper describes how to do it with only a pointer-sized compare-and-swap. So I'm going to go ahead and remove this claim. – 128.151.69.131 (talk) 16:38, 21 March 2008 (UTC)

Also the sentence above it suggests that cmpxchg16b is only useful for updating a global counter. This isn't true either. –128.151.69.131 (talk) 16:40, 21 March 2008 (UTC)

I've changed this now to reflect my concerns. Hopefully someone else can also look at it. –128.151.69.131 (talk) 16:57, 21 March 2008 (UTC)

[edit] "Renamed" should be "named", AMD deserves credit.

The current (A80416) article version says: "x86-64 was designed by AMD, who have since renamed" ...

I propose: "designed by AMD engineers, and the architecture was accordingly named AMD64

Weren't there other names for the actual processors? (like "Hammer"?)

That's not correct; AMD originally called the 64-bit extended instruction set "x86-64", and later renamed it to AMD64 for marketing reasons. Alexthe5th (talk) 05:31, 19 May 2008 (UTC)