This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 |
Wouldn't it be more logical to have a red background for "Yes" and a green background for "No" in the "Compiled-application rebuild required"-field of the "Operating modes"-diagram? —Preceding unsigned comment added by 63.80.93.152 ( talk) 21:58, 30 July 2008 (UTC)
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)
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.
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)
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)
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)
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:
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)
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
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)
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)
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)
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)
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)
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)
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)
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)
"... 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)
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)
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)
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)
Article says:
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)
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)
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"?)
1. Mainstream application problems:
- No Adobe Flash for x64 - means you need to run the web browser in 32-bit mode. (I know about npwiever, it's a hack.)
- No Skype (Ubuntu), only with workarounds.
- etc.
2. Double memory usage of some apps - ie. Java. (Basically means, that it has no sense to upgrade from 4GB 32bit to a 64bit platform, unless you jump right at >8GB 64bit.)
3. Not really faster than 32-bit, AFAIK. Really the only reason is to run memory extremely intensive applications.
x86-64 is great, but for average consumer it was strongly overhyped (by AMD), and still is nowhere near the 32-bit marketshare (IMHO). —Preceding unsigned comment added by 88.101.193.91 ( talk) 23:37, 30 June 2008 (UTC)
Why Terabyte, Exabyte ecc. instead Tebibyte, Exbibyte that are the natural prefix? —Preceding unsigned comment added by 87.13.70.45 ( talk) 18:47, 14 July 2008 (UTC)
I was just wondering if it were possible to install/run an x86_64 arch type onto an x86 hardware computer. I think I've tested it out before, but I can't remember the results. 66.168.19.135 ( talk) 23:41, 26 July 2008 (UTC)
"x86-64 was designed by AMD, who have since renamed it AMD64."
Have they renamed the instruction set or is AMD64 just the name for their implementation? Also, this claim is central to the article and should have an inline reference. If someone has one, please add it. Otus ( talk) 12:44, 8 August 2008 (UTC)
Would AMD64/Intel64 (using the names from both AMD and Intel, separated by a slash) be too awkward of a name? I thought I'd suggest it since the two largest manufacturers of the architecture don't call it x86-64, and I have yet to see a distributor of software who uses that name. If not, I personally think AMD64 would be a better name, since AMD created the first version of the architecture. -- Evice ( talk) 21:36, 27 August 2008 (UTC)
Im a reading http://en.wikipedia.org/?title=X86-64&oldid=238428961#Intel_64_Implementations
Am I alone to find the first paragraph to be barely readeable? The initial description of developement seems correct, but then the history of the launch (this chip has it, but this does not, but this had etc.) intermixed with others timelines (K8, Xeon, Windows x64 which appeared in March, 2005, BTW) and marketing declinations (servers vs. desktops vs. mobile etc.) makes it really complex to understand, and more nowadays since several years have passed. And it concludes by All [...] CPUs have Intel 64 enabled, as do the Core 2 CPUs, and as will all future Intel CPUs, which is now just wrong if we consider the mobile processors (see Atom). So I edited it rather at large. You can check the diff, and put back what may be needed. 212.111.102.30 ( talk) 11:55, 17 September 2008 (UTC)
The article does not mention if protected mode privilege levels were retained in x86-64 long mode, and to what degree. AMD's white paper seems to state that the CS register is retained, although it does not mention how the CPL bits are treated.
My Google-Fu found a piece of code for the Xen hypervisor that stated that only rings 0 and 3 were used, and that rings 1 and 2 were to be ignored, but it wasn't 100% clear if it was Xen ignoring the rings or x86-64 simply did not provide them.
It might also be interesting to know the level of compatibility with rings 1 and 2 in 'compatibility mode' versus 'legacy mode'.
Dinjiin ( talk) 01:21, 25 September 2008 (UTC)
I altered the introduction a bit, any comments/criticisms? Monolith2 ( talk) 23:31, 26 February 2009 (UTC)
Thanks for the input! I only added the stuff on PowerPC because there was already mention of IA-64, which is not an x86 architecture either. I figured I might as well mention the one other major 64-bit processor and how it was incompatible with x86-64 as well. You're right as far as the part about AMD/Intel cross-licensing -- do you think that topic is worth adding as a section in this article? Or is it irrelevant and better placed somewhere else? Cheers, Monolith2 ( talk) 14:54, 27 February 2009 (UTC)
The end of the #Legal issues is poorly sourced at the moment. One of the sources doesn't say what the article claims except in the comments which are obviously not a reliable source. The other making a specific claim only uses the legal agreement (i.e. a primary source) which has been significantly redacted for confidentiality reasons so comes rather close to OR Nil Einne ( talk) 22:46, 24 October 2009 (UTC)
Does anyone object to me setting up automatic archiving for this page using MizaBot? Unless otherwise agreed, I would set it to archive threads that have been inactive for 60 days.-- Oneiros ( talk) 23:11, 29 December 2009 (UTC)
2010 Office System Driver Beta: Data Connectivity Components http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=c06b8369-60dd-4b64-a44b-84b371ede16d -- 211.127.229.23 ( talk) 11:42, 16 March 2010 (UTC)
The article mentions two different maximum limits for physical memory possible under amd64
First is mentioned under section 1.2 (Architectural features) as below:
Larger physical address space: Current implementations of the AMD64 architecture can address up to 1 TiB (240 or 1,099,511,627,776 bytes) of RAM
then, near the end of the page, it is mentioned under section 4.2 (Older implementations):
Recent AMD64 implementations now provide 256 TiB (281,474,976,710,656 bytes) of physical address space
I think second one is right, it is also corroborated by the following link:
Long_mode#Current_limits
Please check. —Preceding
unsigned comment added by
Gurpreet007 (
talk •
contribs)
09:40, 1 January 2010 (UTC)
The sentence in the lede on compatibility is based on one of the fundamental design features of x86-64: the existing x86 instruction set remains in silicon, thus applications built to the existing x86 instruction set will run on an x86-64 chip just as on any other x86 implementation in silicon.
Yes, there are edge cases where a bad OS implementation or a funky bit of incompatibility may not cause this to always be the case, but you can say the same thing for mask revisions. The point is that these are edge cases, and the lede is not the place to hang an ornament for every conceivable edge case. If you want to add discussions of this type, feel free to do so in the body.-- NapoliRoma ( talk) 17:11, 11 April 2010 (UTC)
I have added the fact that it is possible for a computer to use more than 4 Gigabytes of RAM with a x86-64 CPU compared to a x86-32 CPU. This is one of the most commonly cited advantages I have seen in articles I have read on 64-bit CPUs and 64-bit operating systems but for some reason this was not mentioned in the lead section of the article. A 64-bit CPU theoretically allows for a maximum of 16 Exabytes (16 billion Gigabytes) of RAM. -- GrandDrake ( talk) 21:27, 11 April 2010 (UTC)
As such why not mention the larger amount of RAM possible with the x86-64 architecture in the lead section of the article
I have added and improved the references to the architecture manual (reference 1) in the article. These document the true virtual and physical address limits. Except for the reference in the lede, they now all have page numbers. Please fetch that PDF, read and understand the referenced pages, and see how they support the article text. The virtual address width is theoretically 64 bits - but no AMD64 or Intel64 processor actually implements more than 48 bits. (And Windows only populates 44 bits' worth...) The physical address width is architecturally limited to 52 bits, there are just not any more bits available in the page table format, and current implementations only allow 44 bits. Period, full stop.
n.b.: The only reference that can trump Reference 1 is a later version of Reference 1.
Now it is true that a major motivation for moving to x64 is indeed larger VAS and PAS, and so in acknowledgement of your original point, I have added this point to the lede. I have even stated this as "vastly larger" and put this as the first point in the lede. But they are absolutely not 64 bits wide (and x86 was not limited to 32 bits physical, either). They should not be cited as 64 bits wide in the lede, as that is wrong; simply mentioning the true limits without explanation would violate the "principle of least astonishment", as many (like yourself) believe that they are 64 bits wide; and explaining the true limits, the difference between architectural vs. implementation limit, etc., would be too much detail for the lede: by the time you are done explaining it all adequately you have basically duplicated the text that appears later. No, "vastly larger" will suffice completely for the lede. (In general, anything that requires detailed refs doesn't belong in an article lede, particularly for an article as long and as detailed as this one.) Jeh ( talk) 19:56, 25 May 2010 (UTC)
The x86 architecture provides support for translating 32-bit virtual addresses into 32-bit physical addresses (larger physical addresses, such as 36-bit or 40-bit addresses, are supported as a special mode). The AMD64 architecture enhances this support to allow translation of 64-bit virtual addresses into 52-bit physical addresses, although processor implementations can support smaller virtual-address and physical-address spaces.
That's from the bottom of page 115. Now, true, that does not promise that it could "never" be extended beyond that limit. But that isn't how specs are written. If you are claiming that since it is not explicitly excluded then it must be mentioned as a possible future enhancement, then you are firmly in original research and even crystal ball territory. You cannot look at bits 52 through 62, currently unassigned in the PTE format, and say "hm, the physical addresses could grow by 11 more bits!" Well, you can say that to yourself; you could write it in an article at PC Magazine or Wired; but you can't put it in a Wikipedia article based solely on your speculation. We have to take the documented limit for what it is.
Another point is that in the page table, etc., entry formats on page 126, the high 12 bits of the fields (which is where more bits of physical page number would have to go) are documented as "reserved, MBZ" (must be zero). That's in legacy mode. Over on page 131, though, it says that bit 63 is the NX (No eXecute) bit, as we expect, and that bits 52-62 are "available", which means that (like bits 9-11) they are available for the OS to use to stash information. Now once OS code uses them as such, what do you think would happen if a future edition of the processor expanded the physical page address by a few more bits? Things would break. Once AMD has said that field is "available" they can't use it after that without causing a lot of people a lot of pain. The Intel doc similarly says that these bits are "ignored" by the processor in both legacy mode (they call it 32-bit mode, figure 4-7) and "ia32e mode" (table 4-14 through 4-19).
Regarding your references:
In sum, I'm afraid that most of your references are evidence that articles like this one need to be edited only by subject matter experts. As I said many days and a few thousand talk page words ago, there's a lot of confusion out there about these points, and a lot of confused people are writing things on the net. I'm afraid it does take a SME to figure out which references can be trusted and which are "not even wrong." And even of the ones you've given that are reliable, none of them really come out and say "the architectural limit is this, and the current implementation limit is that" in a straightforward manner. The AMD (and, now referenced, Intel) architecture books do so: they directly, obviously, and unambiguously support the article text. And so those are the references that should remain.
I am however going to add your refs 9 and 11 to the section on Windows. Jeh ( talk) 11:45, 29 May 2010 (UTC)
Although a 64-bit processor could theoretically address 16 exabytes of memory (2^64), ... current x64 CPUs typically only allow 40 bits (1 terabyte) of physical memory to be accessed. The architecture (but no current hardware) can extend this to up to 52 bits (4 petabytes).
In general, any source must be considered of low quality (at least as far as referencing these points is concerned) if any of the following apply:
Jeh ( talk) 21:05, 29 May 2010 (UTC)
During a discussion I had concerning information about theoretical RAM size for the x86-64 CPU I was told that there were page numbers attached to the references in question. It was only late into that discussion I noticed that the page numbers for that reference had been put into the article as small numbers after the reference link. Though the Template:Rp can be used it states that:
Warning
This template should not be used unless necessary. In the vast majority of cases, citing page numbers in the [ref ...]...[/ref] code is just fine. This template is only intended for sources that are used many, many times in the same article, to such an extent that normal citation would produce a useless line in [references /] or too many individual ones. Overuse of this template will make prose harder to read, and is likely to be reverted by other editors. Used judiciously, however, it is much less interruptive to the visual flow than full Harvard referencing and some other reference citation styles.."
I do not see any references in question being used to such an extent that it would make sense to use this template and in one case this template is used for a reference that is only used once. -- GrandDrake ( talk) 07:50, 1 June 2010 (UTC)
You should follow the style already established in an article, if it has one; where there is disagreement, the style used by the first editor to use one should be respected.
In the section about larger virtual address space, there was a comment about mmapping being generally faster than using "read" calls. This is not true, although lots of people think it is. It is if you access just a few pages in the whole file, so that the rest of the file can stay on the disk. However when you access MOST of the file, read usually wins out. This is because the operating system as well as the disk tend to catch on to the fact that you're reading the whole file, and tend to do appropriate read-aheads. This doesn't happen if you access the file through a mmapped region.... I changed "generally" to "sometimes". -- REW
Why did AMD limit the physical address space to 52-bits with the x86-64? With the physical address space only bits 0 through 51 are currently allowed while bits 52 through 62 are either reserved with AMD64 (as seen on page 128) or ignored with Intel64 (as seen on page 4-36) and the 63rd bit is used for the NX bit. This currently limits the physical address space to 52-bits even though the virtual address space can go up to 64-bits. Has either AMD or a reliable source given a reason for why the physical address space is limited to 52-bits with the x86-64? -- GrandDrake ( talk) 05:23, 3 June 2010 (UTC)
To GrandDuke:
One: You need to completely decouple the concepts of "integer register width" and "physical address width" in your mind. They are not necessarily related. There is no real reason to think that physical addresses on x64 "ought to be" the same width as the integer register width... so there is no point in looking for reasons that the sizes don't match.
Indeed, the fact that they do match on x86 without PAE is really just a coincidence of the PTE format. If, for example, x86's page tables had one more "reserved for software" bit, or if they had thought of the NX bit and put it in bit 31 of the PTE, we would have a 31-bit PA limit there.
I suspect that generalizing from x86's 32-bit PA is leading you astray. But that is really more of an exception than a typical case.
I've given examples of VA/PA mismatches before. I'll give you a few more. We'll start with the PDP-11. It is of course a 16-bit processor; all integer registers, including those that are always used to provide memory addresses (such as the program counter and the stack pointer) are 16 bits wide. Now on the most primitive PDP-11's there was no MMU... but on others the MMU allowed 18-bit physical addresses. On the higher-end Q-bus versions, and on still others with a dedicated memory bus like the 11/70, they supported 22-bit physical addresses.
For yet another example, this one from Intel: The 8088 was a 16-bit processor with a segmenting mechanism that allowed 20-bit PAs.
And yet another: One of the most successful architectures in history, IBM System/360, originally was a 32-bit processor with 24-bit physical addresses.
You can find similar examples throughout the history of MMU-equipped machines.
Two: I don't consider a limit that is "only" 1024 x 1024 x the typical 4 GB of a modern "largish" PC to be very "limited." That's six orders of (decimal) magnitude. It has taken about 20 years to expand typical RAM configurations by just three orders of magnitude (from 4 MB in the early 90s to 4 GB in 2010). Assuming a factor of 10 every 6 years, that gives 52-bit addresses about 36 years before they become "limiting." Even if the rate suddenly doubles, we still have almost 18 years. Assuming that x86-64 survives that long, there is ample time for a PAE-like extension to be added.
And finally, Three: There is a reason for leaving bits 53 through 62 available to the OS. I don't have a RS for all of this but I do have "insider information"; searches for this might help you find a RS: AMD consulted extensively with various OS kernel engineers, including to my certain knowledge some from MS and some from the Linux kernel community, in architecting the "system programming" features of x86. One thing they heard often was that OS memory management code could benefit from having more bits in the page table entries in which to store information, even for valid PTEs. So, they got them. Windows and, I believe, Linux both use those bits for a "working set index."
Searching for "working set index" and "page table entry" will find some evidence that this is true. For example, one of the reason codes for Windows bugcheck 1A means "the working set index in the page table entry is corrupted." Reliable evidence that AMD deliberately reserved those bits for that and similar purposes, at OS engineers' request, will be tougher or likely impossible to find.
But really, back to point one: Looking for a reason why "it's not the same as the machine bit width" is really misunderstanding the principle. It isn't supposed to be the same. There is no reason, other than a mistaken extrapolation from one example in recent history, to expect them to be the same. So I don't consider that it's needful to find an explanation for why they're not the same. The PTE format allows for a total of 52 bits of physical address, and that is that. Conversely, the point that there's no reason to expect them to be the same is not specific to x64 and so doesn't belong here. Jeh ( talk) 07:32, 3 June 2010 (UTC)
In Talk:X86-64#Why does the physical address space matter? several well-informed editors made convincing arguments that 32bit computers can access more than the 2^32=4GiB memory through various tables and address translations. But I am just a programmer, and the way it looks to me is that on 32 bit system I get a 32bit flat address space and cannot allocate over 2 or 3 or 4GB (depending on Windows or Linux flavor), my pointers are 32bit integers. My process simply cannot address more memory that 4GB. (Sure the hardware and the OS can create many flat addressable spaces each 4GB in size. Useful to the OS but not to my process.) On a 64bit system (hw+os) I do not have this limitation, my pointers are 64bit integers and I can go over the 4 GB limit, even in a single malloc to allocate a large array. So... isn't this a good reason to say in the article lead that 64bit allows to access more than 4GB memory? Jmath666 ( talk) 07:54, 9 June 2010 (UTC)
Agreed. Well, can you think of a way to put 4GiB somewhere in the article lede, please? Overcoming the 4GiB limit (of what user code can malloc) is the whole point of the 64bit transition to my clients. They just want to solve on cheap Windows or Linux machines the big engineering models they did on expensive Unix workstations, which went through the 64bit transition many years earlier. We just use the computers, rather than designing them. Thanks, Jmath666 ( talk) 08:58, 9 June 2010 (UTC)
HumphreyW, on the issue of undue weight if anything the information on the physical address space is lacking. Despite being one of the top three issues mentioned by articles I have read on the x86-64 at the moment the physical address space is given a single paragraph in the middle of the "Architectural features" section with no explanation given for why the physical address space matters. -- GrandDrake ( talk) 23:14, 3 June 2010 (UTC)
Well, I have since re-thought that position. In fact I think that what the article needs are referenced statements noting that increased physical address space beyond x86's 36 bits is really not a big deal for the vast majority of users.
First: A statement, no matter how well referenced, that RAM is faster than a hard drive is irrelevant to a description of x64's architectural changes; it rather belongs in an article comparing various data storage technologies. To put it the other way around - If it applies here then it applies just as well to the articles on PAE, on Itanium, and on other architectures with larger physical address spaces than their predecessors... going all the way back to 8088 vs. 8008 in the microcomputer field, and much farther than that in computing in general.
As for "consensus", consensus is represented by the previous state of the paragraph in question, which has been essentially stable for many many months. Yes, consensus can change, and for that, agreement is essential. You need to reach agreement with other parties for this change and I for one certainly am not in agreement that this material belongs here.
Second: a statement that "RAM is faster than a hard drive" (Really? You don't say? Imagine that!) is obvious to the point of being trite. Providing four different references to "defend" it, and then making essentially the same statement again, and using the same four references for the restatement, is being pedantic to the point of obnoxiousness; it's like making a statement that "trains roll better if they use round wheels instead of hexagonal" and then looking up a bunch of "references" to back it up. Even in an article where this statement needs to be made (perhaps, again, an article comparing various data storage technologies) these "references" are supporting a statement that no one is ever likely to challenge and therefore need not be supported by references at all. At most one reference would be completely sufficient... preferably to something like performance specifications.
Third: x64's vastly increased physical address limit is a moot point for the vast majority of users, except for the way Microsoft has chosen to support large RAM configurations, and the notion that we needed x64 to "break the 4 GB RAM barrier" is at best misleading. Allow me to explain.
Very few computers with x86 CPUs these days have CPUs that are not capable of PAE; netbooks are the only common exception. In other words, most x86 CPUs these days can address 64 GB RAM. They have had this capability since the Pentium Pro. Remember that many of the x86 "server" editions of Windows 2000 and 2003 Server do support more than 4 GB RAM - they do this via PAE, of course. [1]
It is only an implementation decision of Microsoft's to not support PAs more than 32 bits wide on their "client" versions of Windows (XP, Vista, and 7). [2]
The "4 GB RAM" limit of x86 is therefore largely a myth; it is a constraint imposed by the Windows OS, nothing more.
And the notion that we needed x64 at a hardware level to let us break this supposed 4GB barrier is therefore also a myth.
The way in which x64 does allow most users (those running Windows "client" OSs like Windows Vista or Windows 7) to use more than 4 GB RAM is very indirect: By using an x64 processor with a Microsoft x64 OS, you are using an OS which Microsoft has not "hamstrung" to 32-bit physical addresses.
The x64 physical address myth goes further than that. It is true that x64 allows RAM to go to 4 petabytes instead of the "mere" 64 GB permitted by PAE under x86, but really, 64 GB is already far outside of the amount that is likely to be put in most PCs anytime soon; or in fact, is even possible for installation, given chipset and DIMM slot limitations. I do happen to have a server class Xeon mobo here that can take up to 144 GB RAM with currently available DIMMs, but it is very much the exception, and even that would require 8 GB DIMMs, which are like hen's teeth and not supported by most consumer boards. The typical "desktop" or "deskside" motherboard has perhaps four or six DIMM slots supporting at most 4 GB DIMMs.
SO... In sum, I agree (even more than I did before) with HumphreyW: undue weight is even now being given to x64's 52-bit PA space. Yes, x64 allows users of Windows client OSs will be able to use more than 4GB of RAM for the first time. But they could have done that on x86 by using Windows Server OSs, or any of a number of Linux releases. Yes, x64 users will be able to use more than 64 GB of RAM... but for most applications, motherboards and DIMM configurations supporting even 64 GB are well in the future and more than 64 GB are farther away still. Jeh ( talk) 02:56, 8 June 2010 (UTC)
The statement that increased RAM helps "up to a point" is ambiguous and makes it sound like there is a hard limit. Since the phrase "which depending on the programs that are running can improve performance" is already conditional I don't see the need to add an ambiguous statement to the end of it. And different programs depending on different situations will vary in whether/how beneficial additional RAM would be (such as is the case with the 64-bit version of Photoshop). Instead of the article saying "which depending on the programs that are running can improve performance, up to a point" it says "which depending on the programs that are running can improve performance; though programs will have various points of diminishing returns." Would that be acceptable?
Also in regards to the references one links to what I believe is the wrong article since it doesn't have the quote that the reference uses and the information about the reference doesn't match up. The other reference is discussing the issue of the point of diminishing returns based on current price and performance for the Mailbox server role of Exchange Server 2010. -- GrandDrake ( talk) 01:28, 10 June 2010 (UTC)
Current AMD64 implementations support a physical address space of up to 248 bytes of RAM, or 256 TB (281,474,976,710,656 bytes). [3] This is a large increase over the limit imposed by x86 processors. In practice, the importance and meaning of this increased RAM capacity depends on a variety of factors, including the operating system chosen.
Since there is a disagreement on this point should x86 be used to refer to 32-bit x86 for processors? I ask since there should be a consistent term used when referring to 32-bit x86 in the article and at the moment the article has "x86", "32-bit x86", and "x86-32". Also should this apply to statements about programs where x86 is mentioned such as with "32-bit x86 executables"?
Every time a memory (p. or v.) size limit is mentioned there is text like this:
therefore can address up to 256 TB (248 or 281,474,976,710,656 bytes) of RAM.
It's repetitious in the extreme, very visually annoying.
Isn't there a better way to do this?
Idea: there are only a few different values actually used. Each of them could have its own note (and the notes and references section would be split into two, keeping the notes separate). So for example, 256 TB would appear as 256 TB[note 1], and note 1 would say "256 TB equals 248 or 281,474,976,710,656 bytes (approximately 280 x 1012." The current footnote template that says that since we're talking about semiconductor memory, these units are being used in their binary sense, would go in the notes section as well.
This might be good enough to start a new trend. Comments?
Jeh ( talk) 08:59, 10 June 2010 (UTC)
The AMD 64bit srchitecture specifically included the prefetch instructions in the interface, the early Intel 64bit processors didn't support this and at least a couple of first 64bit revs of Linux didn't run on Intel CPUs for that reason. Alan Cox ( talk) 22:03, 18 June 2010 (UTC)
One problem I notice in this article is that there is a bias in how the physical/virtual address space are portrayed. For comparison this is how the details of the 4 GB per process virtual address space limit is given:
"This is compared to just 4 GB (232 bytes) for the x86"
Not exactly a detailed explanation and compare that to how the physical address space limit is given:
"For comparison, x86 processors are limited to 64 GB of RAM in Physical Address Extension (PAE) mode,[7], or 4 GB of RAM without PAE mode." "In fact almost all x86 processors (from the Pentium Pro onward) can address up to 64 GB of RAM via physical address extension (PAE) a modification of the address translation scheme that is otherwise used.[7] Many x86 operating systems, including some versions of Windows Server, support this.[13][14][15] Provided that the operating system supports more than 4 GB of RAM, the increased physical addressing capability of AMD64 would therefore only be needed in systems requiring (and physically able to accommodate) at least 64 GB of RAM." "...even though x86 processors do not actually impose a 4 GB limit."
The 64 GB physical address space limit is noted clearly in several sentences while the virtual address space limit of 4 GB per process is not explained clearly in even one sentence. Attempts to clearly note the 4 GB per process virtual address space limit have been deleted. -- GrandDrake ( talk) 06:48, 19 June 2010 (UTC)
Note that the following two statements are unreferenced and repeat what earlier referenced statements had said:
"Provided that the operating system supports more than 4 GB of RAM, the increased physical addressing capability of AMD64 would therefore only be needed in systems requiring (and physically able to accommodate) at least 64 GB of RAM." "...even though x86 processors do not actually impose a 4 GB limit."
When I tried to delete them I was told that they were part of the narrative but at the moment that narrative looks biased by repeating information about one fact while ignoring a different fact. The average person who reads this article could easily come away from it thinking that they don't need x86-64 in regards to RAM since current 32-bit CPUs support 64 GB of RAM while never knowing that there is a 4 GB per process limit due to the 32-bit virtual address space. -- GrandDrake ( talk) 07:18, 19 June 2010 (UTC)
HumphreyW, on the issue of undue weight if anything the information on the physical address space is lacking. --GrandDrake (talk) 4:14 pm, 3 June 2010, Thursday (16 days ago) (UTC−7)
I have added the fact that it is possible for a computer to use more than 4 Gigabytes of RAM with a x86-64 CPU compared to a x86-32 CPU. This is one of the most commonly cited advantages I have seen in articles I have read on 64-bit CPUs and 64-bit operating systems but for some reason this was not mentioned in the lead section of the article.
-- GrandDrake ( talk) 21:27, 11 April 2010 (UTC)
The 4 GB VAS limit for the x86-64 legacy mode is not mentioned in the article. The AMD architecture specs is very clear that the VAS in legacy mode is limited to 32-bits. Since legacy mode is a part of the x86-64 architecture I think the 4 GB VAS limit in legacy mode should be mentioned at least once in the article. After consideration I agree that it would make the most sense to put that information in the legacy mode section. Are there any objections to including this information in the legacy mode section of the article? -- GrandDrake ( talk) 08:46, 24 June 2010 (UTC)
I have an issue with the statement about AMD losing the rights to manufacture x86 architecture chips. The original x86 patents are definitely expired now. Anyone can manufacture x86 compatible chips now. I haven't seen the agreement between AMD and Intel. That would be controlling, but I doubt the contract can enforce rights on expired patents.-- Celtic hackr ( talk) 17:19, 28 November 2010 (UTC)
"However, AMD64 still has fewer registers than many common RISC ISAs (which typically have 32–64 registers) or VLIW-like machines such as the IA-64 (which has 128 registers); note, however, that because of register renaming the number of physical registers is often much larger than the number of registers exposed by the instruction set."
Processors such ATOM without out-of-order execution engine, so does not have internal re-naming registers at all. Meanwhile, even though the Itanium architecture has 128 Gerneral registers, but implementations could contain much more registers than this without exposing to the user interface, similar with SPARC implementation with instruction windowing mechanism to access them. So the actual physical register number different among implementations, and should not be used to mention for some a specific architecture.
On the other hand, even though processor such as Intel Core 2 have potential much more physical registers to accelerate the internal out-of-order pipeline engine, because lack of huge architecture-level registers, most of compute operations are achieved with accessing the system memory. Meanwhile, Itanium has hugh architecture-level registers, some operations could be achieved without interfering external memory. The implementation register could not change this sematic behaviour. — Preceding unsigned comment added by 221.9.20.7 ( talk) 22:10, 11 June 2011 (UTC)
Is x87 code set still supported in native 64-bit Long Mode ? Or not ? The question is because x64's native SSE2 floating point instructions only can do with 8-bytes floating point. x87 could have more precision, even if with less speed. But is it possible at all ? It seems that Delphi XE2 Win64 compiler does not do x87. Is it inpossible due to hardware, or they just decided tosimplify things for themselves? 79.111.218.128 ( talk) 20:09, 30 September 2011 (UTC)
Unregistered editor 83.108.118.234 ( talk) edited the Linux section of the article as shown here, twice with the notably uncivil comment
Pretty sure the alledged [sic] 64-TB limit is bullshit.. afaik the linux64 kernel can handle close to 17 billion gigabytes of ram (aka ~16600000 TB))
If you're using "decimal billion" consistently that number would actually be 18 billion billion, that is, about 18.4×1018 bytes, i.e. 264.
However no operating system on x64 can support that much RAM (or that much virtual address space either), because the processors don't support it. Under the current architecture definitions these CPUs can provide a maximum of 256 TiB (248) of virtual address space, and 4 PiB (252) of physical address space (RAM); current implementations are further limited to 256 TiB of RAM (48 bits of physical address). That's all the bits that are implemented.
This is well described, with good references to the AMD docs, in the relevant sections of the article ("Virtual address space details" and "Physical address space details". There is also a very lengthy discussion of why this is so in the talk page archive here, section 33. (In response to someone else who didn't believe it.)
It is possible of course that a future change to the architecture could allow more than 48 bits of virtual address, or more than 52 bits of physical. But in the meantime, any statement regarding any OS running on x64 that claims implementation of more than 256 tebibytes of virtual address space, or of more than 4 pebibytes of physical address space (RAM), is simply wrong. It just isn't possible.
I'm removing the "dubious" template but leaving the "citation needed". Even though the IP's notion that a full 64-bit address space (either one) is supported by Linux64 simply cannot be true, a citation would still be nice for the limit that is claimed there. Jeh ( talk) 03:40, 3 October 2011 (UTC)
The AMD64 architecture defines a 64-bit virtual address format, of which the low-order 48 bits are used in current implementations.[1](p120) This allows up to 256 TB (248 bytes) of virtual address space. The architecture definition allows this limit to be raised in future implementations to the full 64 bits...
The AMD64 architecture enhances the legacy translation support by allowing virtual addresses of up to 64 bits long to be translated into physical addresses of up to 52 bits long. Currently, the AMD64 architecture defines a mechanism for translating 48-bit virtual addresses to 52-bit physical addresses. The mechanism used to translate a full 64-bit virtual address is reserved and will be described in a future AMD64 architectural specification.
The PAE-paging data structures support mapping of 64-bit virtual addresses into 52-bit physical addresses.
Is there an article about x32 ABI?-- 78.49.64.83 ( talk) 01:05, 1 November 2011 (UTC)
Frankly, I have never seen x86-64 outside Wikipedia. All software vendors seem to like to use x64. But how about verifiable facts? Which ones is used more often? x64 or x86-64? Fleet Command ( talk) 12:28, 21 June 2011 (UTC)
Is there a strong reason for mentioning that x86-64 and IA-64 are not the same thing? If we do mention that, then we should also mention that x86-64 does not also relate with Alpha, MIPS64, POWER/PowerPC 64-bit, and other important 64-bit architectures. It is either all or none.
Note: I saw someone revert my edit with a comment regarding that Windows can run both on x86-64 and IA-64. So what? Linux does too, and on all of the architectures mentioned above. World doesn't revolve around Windows, so we won't make useless remarks just because of it and generic consumer's ignorance. The second point of the person aforementioned was that IA-64 and Intel 64 are both made by Intel. It could be somewhat relevant if this article were about Intel 64, but it isn't; it is about x86-64 in general — an ISA subset common to both AMD64 and Intel 64, i.e. a vendor-neutral specification.
We already have a line by the header, which reads: "[...] For the Intel 64-bit architecture called IA-64, see Itanium." — That is quite enough. 95.220.134.217 ( talk) 19:35, 10 March 2012 (UTC)
To make it more objective I changed the title of the section "Legal issues of the AMD-Intel duopoly" to simply "Licensing issues". I also removed some speculation and unrelated information. -- GrandDrake ( talk) 06:16, 24 March 2012 (UTC)
Recent edits have mentioned max ram for Windows server 2006 and 2012. It looks to me based upon this:
http://blogs.technet.com/b/schadinio/archive/2011/02/23/windows-server-2008-2008-r2-max-memory.aspx
...that there is no one number we can put in the article. So, should we try to show the range of numbers, or just not mention Windows server 200X memory? -- Guy Macon ( talk) 17:29, 2 June 2012 (UTC)
Just saying. 136.169.53.84 ( talk · contribs) 01:15, 23 September 2012 (UTC)
Hi, I just came across this page from a link on the Windows Server 2008 page, since I wasn't sure about what the different abbreviations where for the architectures under Editions and System requirements. I thought x86 was always about 32-bit and x64 was 64-bit. This is how Microsoft labels their downloads at least. When I got to this page (in English) I got confused when just looking at the beginning where is says "x86-64 is an extension of the IA-32 32-bit version". An extension can be many things, so I got confused, but when reading another language ( Danish) I figured out that it actually is 64-bit. So my suggestion is to change the intro a bit and start telling that "this is 64-bit" and then go on. What do you think about that? If you agree, then just update it. I don't have a suggestion right now about how to write it. / PatrikN ( talk) 23:05, 15 November 2012 (UTC)
Added information on video game consoles that use x86-64. I was able to find information on how RAM is reserved for the Xbox One but was not able to find that information for the PlayStation 4. -- GrandDrake ( talk) 19:53, 3 June 2013 (UTC)
No. The reference given shows 128 TB usable for kernel space under Windows 8.1, but still only 8 TB in user space. The 128 GB in user space is only for Itanium versions. The needed phraseology is not straightforward because this is nevertheless using all 48 bits.
Perhaps a good wording would be this: Windows, prior to Windows 8.1, only populated 16 TB of the virtual address space. Jeh ( talk) 17:26, 20 January 2014 (UTC)
Ok, who's good with editing these SVG files? I would like to request that Image:AMD64-canonical--48-bit.svg and Image:AMD64-canonical--56-bit.svg be modified to include the text "(not to scale)" under the text "Noncanonical addresses".
If we were not trying to be so encyclopedic we could write "very much not to scale" instead. In the 48-bit diagram, the two canonical halves would be each 1/131072 of the total height. i.e. a tiny fraction of a pixel high! In the 56-bit picture the two halves would each be 1/512 of the total height, which still would not be an entire pixel on most screens... but it would be getting close to one.
Maybe we just need a "relative sizes not to scale" notation at the bottom of the whole thing. Jeh ( talk) 09:15, 22 January 2014 (UTC)
Even without the excessive lower-byte registers, the table is not working for me. It is not the case, for example, that there is one register of which EIP is the low 32 bits and RIP is the high. But that's what the table/diagram shows. I think all of the short forms should be removed in the short term. e.g. RIP would just show RIP. Jeh ( talk) 21:18, 14 February 2014 (UTC)
The Long mode section contained this
Real-mode programs and programs that use virtual 8086 mode at any time cannot be run in long mode unless they are emulated in software.
Which was deleted by Someone not using his real name ( talk · contribs) with a rather WP:POINTy edit comment.
I have restored it. Here's why: The method described in Virtual 8086 mode is
The addition of VT-X has added back the ability to run virtual 8086 mode from x86-64 long mode, but it has to be done by transitioning the (physical) processor to VMX root mode and launching a logical (virtual) processor itself running in virtual 8086 mode.
Westmere and later Intel processors usually[c] can start the logical processor directly in real mode using the "unrestricted guest" feature (which itself requires Extended Page Tables); this method removes the need to resort to [the nested] virtual 8086 mode simply to run some MS-DOS application.
See, you're still not running the real mode or virtual 8086 mode app under long mode! Of course you can run, as in start, such a program while using a long mode operating system... as long as you do it by creating a whole new virtual processor, which itself can run in the desired mode (Virtual 8086 or real mode). Heck, you could also have a second machine handy running an x86 OS and send the old binary to it for execution...
...But the restriction on running such programs in or under long mode is still there. As it says in the AMD doc (whose cite I just updated), page 11, note 3:
Long mode supports only x86 protected mode. It does not support x86 real mode or virtual-8086 mode.
I did acknowledge the possibility of getting around this restriction via VT-X, by appending this to the restored sentence:
However, such programs may be started from an operating system running in long mode on processors supporting VT-X, by creating a virtual processor running in the desired mode.
I believe this covers it, better than the original sentence did, and certainly better than the article did without that sentence.
However, I'm not sure what the big deal is about VT-X here. You could run a DOS app under x64 Windows (or, I believe, Linux) by using any of a number of virtual machine hosts—DOSbox having been specifically promoted for that purpose—long before VT-X existed. Jeh ( talk) 07:19, 18 February 2014 (UTC)
I think we should put an image in the lead section. Any ideas? The supercomputing cluster adoption chart looks best in its own section. Maybe we could use the logos of AMD64 and Intel64, or a photo of the first x86-64 processor (AMD Opteron). What would you suggest? Sofia Koutsouveli ( talk) 01:27, 20 March 2014 (UTC)
Hi. I'm thinking about low-resolution versions of "AMD64 Architecture Programmer’s Manual" and/or "Intel 64 and IA-32 Architectures Software Developer’s Manual", if that's allowed by the law. Dannyniu ( talk) 03:10, 14 June 2014 (UTC)
amd10h
was invoked but never defined (see the
help page).This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 |
Wouldn't it be more logical to have a red background for "Yes" and a green background for "No" in the "Compiled-application rebuild required"-field of the "Operating modes"-diagram? —Preceding unsigned comment added by 63.80.93.152 ( talk) 21:58, 30 July 2008 (UTC)
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)
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.
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)
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)
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)
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:
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)
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
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)
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)
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)
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)
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)
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)
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)
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)
"... 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)
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)
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)
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)
Article says:
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)
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)
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"?)
1. Mainstream application problems:
- No Adobe Flash for x64 - means you need to run the web browser in 32-bit mode. (I know about npwiever, it's a hack.)
- No Skype (Ubuntu), only with workarounds.
- etc.
2. Double memory usage of some apps - ie. Java. (Basically means, that it has no sense to upgrade from 4GB 32bit to a 64bit platform, unless you jump right at >8GB 64bit.)
3. Not really faster than 32-bit, AFAIK. Really the only reason is to run memory extremely intensive applications.
x86-64 is great, but for average consumer it was strongly overhyped (by AMD), and still is nowhere near the 32-bit marketshare (IMHO). —Preceding unsigned comment added by 88.101.193.91 ( talk) 23:37, 30 June 2008 (UTC)
Why Terabyte, Exabyte ecc. instead Tebibyte, Exbibyte that are the natural prefix? —Preceding unsigned comment added by 87.13.70.45 ( talk) 18:47, 14 July 2008 (UTC)
I was just wondering if it were possible to install/run an x86_64 arch type onto an x86 hardware computer. I think I've tested it out before, but I can't remember the results. 66.168.19.135 ( talk) 23:41, 26 July 2008 (UTC)
"x86-64 was designed by AMD, who have since renamed it AMD64."
Have they renamed the instruction set or is AMD64 just the name for their implementation? Also, this claim is central to the article and should have an inline reference. If someone has one, please add it. Otus ( talk) 12:44, 8 August 2008 (UTC)
Would AMD64/Intel64 (using the names from both AMD and Intel, separated by a slash) be too awkward of a name? I thought I'd suggest it since the two largest manufacturers of the architecture don't call it x86-64, and I have yet to see a distributor of software who uses that name. If not, I personally think AMD64 would be a better name, since AMD created the first version of the architecture. -- Evice ( talk) 21:36, 27 August 2008 (UTC)
Im a reading http://en.wikipedia.org/?title=X86-64&oldid=238428961#Intel_64_Implementations
Am I alone to find the first paragraph to be barely readeable? The initial description of developement seems correct, but then the history of the launch (this chip has it, but this does not, but this had etc.) intermixed with others timelines (K8, Xeon, Windows x64 which appeared in March, 2005, BTW) and marketing declinations (servers vs. desktops vs. mobile etc.) makes it really complex to understand, and more nowadays since several years have passed. And it concludes by All [...] CPUs have Intel 64 enabled, as do the Core 2 CPUs, and as will all future Intel CPUs, which is now just wrong if we consider the mobile processors (see Atom). So I edited it rather at large. You can check the diff, and put back what may be needed. 212.111.102.30 ( talk) 11:55, 17 September 2008 (UTC)
The article does not mention if protected mode privilege levels were retained in x86-64 long mode, and to what degree. AMD's white paper seems to state that the CS register is retained, although it does not mention how the CPL bits are treated.
My Google-Fu found a piece of code for the Xen hypervisor that stated that only rings 0 and 3 were used, and that rings 1 and 2 were to be ignored, but it wasn't 100% clear if it was Xen ignoring the rings or x86-64 simply did not provide them.
It might also be interesting to know the level of compatibility with rings 1 and 2 in 'compatibility mode' versus 'legacy mode'.
Dinjiin ( talk) 01:21, 25 September 2008 (UTC)
I altered the introduction a bit, any comments/criticisms? Monolith2 ( talk) 23:31, 26 February 2009 (UTC)
Thanks for the input! I only added the stuff on PowerPC because there was already mention of IA-64, which is not an x86 architecture either. I figured I might as well mention the one other major 64-bit processor and how it was incompatible with x86-64 as well. You're right as far as the part about AMD/Intel cross-licensing -- do you think that topic is worth adding as a section in this article? Or is it irrelevant and better placed somewhere else? Cheers, Monolith2 ( talk) 14:54, 27 February 2009 (UTC)
The end of the #Legal issues is poorly sourced at the moment. One of the sources doesn't say what the article claims except in the comments which are obviously not a reliable source. The other making a specific claim only uses the legal agreement (i.e. a primary source) which has been significantly redacted for confidentiality reasons so comes rather close to OR Nil Einne ( talk) 22:46, 24 October 2009 (UTC)
Does anyone object to me setting up automatic archiving for this page using MizaBot? Unless otherwise agreed, I would set it to archive threads that have been inactive for 60 days.-- Oneiros ( talk) 23:11, 29 December 2009 (UTC)
2010 Office System Driver Beta: Data Connectivity Components http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=c06b8369-60dd-4b64-a44b-84b371ede16d -- 211.127.229.23 ( talk) 11:42, 16 March 2010 (UTC)
The article mentions two different maximum limits for physical memory possible under amd64
First is mentioned under section 1.2 (Architectural features) as below:
Larger physical address space: Current implementations of the AMD64 architecture can address up to 1 TiB (240 or 1,099,511,627,776 bytes) of RAM
then, near the end of the page, it is mentioned under section 4.2 (Older implementations):
Recent AMD64 implementations now provide 256 TiB (281,474,976,710,656 bytes) of physical address space
I think second one is right, it is also corroborated by the following link:
Long_mode#Current_limits
Please check. —Preceding
unsigned comment added by
Gurpreet007 (
talk •
contribs)
09:40, 1 January 2010 (UTC)
The sentence in the lede on compatibility is based on one of the fundamental design features of x86-64: the existing x86 instruction set remains in silicon, thus applications built to the existing x86 instruction set will run on an x86-64 chip just as on any other x86 implementation in silicon.
Yes, there are edge cases where a bad OS implementation or a funky bit of incompatibility may not cause this to always be the case, but you can say the same thing for mask revisions. The point is that these are edge cases, and the lede is not the place to hang an ornament for every conceivable edge case. If you want to add discussions of this type, feel free to do so in the body.-- NapoliRoma ( talk) 17:11, 11 April 2010 (UTC)
I have added the fact that it is possible for a computer to use more than 4 Gigabytes of RAM with a x86-64 CPU compared to a x86-32 CPU. This is one of the most commonly cited advantages I have seen in articles I have read on 64-bit CPUs and 64-bit operating systems but for some reason this was not mentioned in the lead section of the article. A 64-bit CPU theoretically allows for a maximum of 16 Exabytes (16 billion Gigabytes) of RAM. -- GrandDrake ( talk) 21:27, 11 April 2010 (UTC)
As such why not mention the larger amount of RAM possible with the x86-64 architecture in the lead section of the article
I have added and improved the references to the architecture manual (reference 1) in the article. These document the true virtual and physical address limits. Except for the reference in the lede, they now all have page numbers. Please fetch that PDF, read and understand the referenced pages, and see how they support the article text. The virtual address width is theoretically 64 bits - but no AMD64 or Intel64 processor actually implements more than 48 bits. (And Windows only populates 44 bits' worth...) The physical address width is architecturally limited to 52 bits, there are just not any more bits available in the page table format, and current implementations only allow 44 bits. Period, full stop.
n.b.: The only reference that can trump Reference 1 is a later version of Reference 1.
Now it is true that a major motivation for moving to x64 is indeed larger VAS and PAS, and so in acknowledgement of your original point, I have added this point to the lede. I have even stated this as "vastly larger" and put this as the first point in the lede. But they are absolutely not 64 bits wide (and x86 was not limited to 32 bits physical, either). They should not be cited as 64 bits wide in the lede, as that is wrong; simply mentioning the true limits without explanation would violate the "principle of least astonishment", as many (like yourself) believe that they are 64 bits wide; and explaining the true limits, the difference between architectural vs. implementation limit, etc., would be too much detail for the lede: by the time you are done explaining it all adequately you have basically duplicated the text that appears later. No, "vastly larger" will suffice completely for the lede. (In general, anything that requires detailed refs doesn't belong in an article lede, particularly for an article as long and as detailed as this one.) Jeh ( talk) 19:56, 25 May 2010 (UTC)
The x86 architecture provides support for translating 32-bit virtual addresses into 32-bit physical addresses (larger physical addresses, such as 36-bit or 40-bit addresses, are supported as a special mode). The AMD64 architecture enhances this support to allow translation of 64-bit virtual addresses into 52-bit physical addresses, although processor implementations can support smaller virtual-address and physical-address spaces.
That's from the bottom of page 115. Now, true, that does not promise that it could "never" be extended beyond that limit. But that isn't how specs are written. If you are claiming that since it is not explicitly excluded then it must be mentioned as a possible future enhancement, then you are firmly in original research and even crystal ball territory. You cannot look at bits 52 through 62, currently unassigned in the PTE format, and say "hm, the physical addresses could grow by 11 more bits!" Well, you can say that to yourself; you could write it in an article at PC Magazine or Wired; but you can't put it in a Wikipedia article based solely on your speculation. We have to take the documented limit for what it is.
Another point is that in the page table, etc., entry formats on page 126, the high 12 bits of the fields (which is where more bits of physical page number would have to go) are documented as "reserved, MBZ" (must be zero). That's in legacy mode. Over on page 131, though, it says that bit 63 is the NX (No eXecute) bit, as we expect, and that bits 52-62 are "available", which means that (like bits 9-11) they are available for the OS to use to stash information. Now once OS code uses them as such, what do you think would happen if a future edition of the processor expanded the physical page address by a few more bits? Things would break. Once AMD has said that field is "available" they can't use it after that without causing a lot of people a lot of pain. The Intel doc similarly says that these bits are "ignored" by the processor in both legacy mode (they call it 32-bit mode, figure 4-7) and "ia32e mode" (table 4-14 through 4-19).
Regarding your references:
In sum, I'm afraid that most of your references are evidence that articles like this one need to be edited only by subject matter experts. As I said many days and a few thousand talk page words ago, there's a lot of confusion out there about these points, and a lot of confused people are writing things on the net. I'm afraid it does take a SME to figure out which references can be trusted and which are "not even wrong." And even of the ones you've given that are reliable, none of them really come out and say "the architectural limit is this, and the current implementation limit is that" in a straightforward manner. The AMD (and, now referenced, Intel) architecture books do so: they directly, obviously, and unambiguously support the article text. And so those are the references that should remain.
I am however going to add your refs 9 and 11 to the section on Windows. Jeh ( talk) 11:45, 29 May 2010 (UTC)
Although a 64-bit processor could theoretically address 16 exabytes of memory (2^64), ... current x64 CPUs typically only allow 40 bits (1 terabyte) of physical memory to be accessed. The architecture (but no current hardware) can extend this to up to 52 bits (4 petabytes).
In general, any source must be considered of low quality (at least as far as referencing these points is concerned) if any of the following apply:
Jeh ( talk) 21:05, 29 May 2010 (UTC)
During a discussion I had concerning information about theoretical RAM size for the x86-64 CPU I was told that there were page numbers attached to the references in question. It was only late into that discussion I noticed that the page numbers for that reference had been put into the article as small numbers after the reference link. Though the Template:Rp can be used it states that:
Warning
This template should not be used unless necessary. In the vast majority of cases, citing page numbers in the [ref ...]...[/ref] code is just fine. This template is only intended for sources that are used many, many times in the same article, to such an extent that normal citation would produce a useless line in [references /] or too many individual ones. Overuse of this template will make prose harder to read, and is likely to be reverted by other editors. Used judiciously, however, it is much less interruptive to the visual flow than full Harvard referencing and some other reference citation styles.."
I do not see any references in question being used to such an extent that it would make sense to use this template and in one case this template is used for a reference that is only used once. -- GrandDrake ( talk) 07:50, 1 June 2010 (UTC)
You should follow the style already established in an article, if it has one; where there is disagreement, the style used by the first editor to use one should be respected.
In the section about larger virtual address space, there was a comment about mmapping being generally faster than using "read" calls. This is not true, although lots of people think it is. It is if you access just a few pages in the whole file, so that the rest of the file can stay on the disk. However when you access MOST of the file, read usually wins out. This is because the operating system as well as the disk tend to catch on to the fact that you're reading the whole file, and tend to do appropriate read-aheads. This doesn't happen if you access the file through a mmapped region.... I changed "generally" to "sometimes". -- REW
Why did AMD limit the physical address space to 52-bits with the x86-64? With the physical address space only bits 0 through 51 are currently allowed while bits 52 through 62 are either reserved with AMD64 (as seen on page 128) or ignored with Intel64 (as seen on page 4-36) and the 63rd bit is used for the NX bit. This currently limits the physical address space to 52-bits even though the virtual address space can go up to 64-bits. Has either AMD or a reliable source given a reason for why the physical address space is limited to 52-bits with the x86-64? -- GrandDrake ( talk) 05:23, 3 June 2010 (UTC)
To GrandDuke:
One: You need to completely decouple the concepts of "integer register width" and "physical address width" in your mind. They are not necessarily related. There is no real reason to think that physical addresses on x64 "ought to be" the same width as the integer register width... so there is no point in looking for reasons that the sizes don't match.
Indeed, the fact that they do match on x86 without PAE is really just a coincidence of the PTE format. If, for example, x86's page tables had one more "reserved for software" bit, or if they had thought of the NX bit and put it in bit 31 of the PTE, we would have a 31-bit PA limit there.
I suspect that generalizing from x86's 32-bit PA is leading you astray. But that is really more of an exception than a typical case.
I've given examples of VA/PA mismatches before. I'll give you a few more. We'll start with the PDP-11. It is of course a 16-bit processor; all integer registers, including those that are always used to provide memory addresses (such as the program counter and the stack pointer) are 16 bits wide. Now on the most primitive PDP-11's there was no MMU... but on others the MMU allowed 18-bit physical addresses. On the higher-end Q-bus versions, and on still others with a dedicated memory bus like the 11/70, they supported 22-bit physical addresses.
For yet another example, this one from Intel: The 8088 was a 16-bit processor with a segmenting mechanism that allowed 20-bit PAs.
And yet another: One of the most successful architectures in history, IBM System/360, originally was a 32-bit processor with 24-bit physical addresses.
You can find similar examples throughout the history of MMU-equipped machines.
Two: I don't consider a limit that is "only" 1024 x 1024 x the typical 4 GB of a modern "largish" PC to be very "limited." That's six orders of (decimal) magnitude. It has taken about 20 years to expand typical RAM configurations by just three orders of magnitude (from 4 MB in the early 90s to 4 GB in 2010). Assuming a factor of 10 every 6 years, that gives 52-bit addresses about 36 years before they become "limiting." Even if the rate suddenly doubles, we still have almost 18 years. Assuming that x86-64 survives that long, there is ample time for a PAE-like extension to be added.
And finally, Three: There is a reason for leaving bits 53 through 62 available to the OS. I don't have a RS for all of this but I do have "insider information"; searches for this might help you find a RS: AMD consulted extensively with various OS kernel engineers, including to my certain knowledge some from MS and some from the Linux kernel community, in architecting the "system programming" features of x86. One thing they heard often was that OS memory management code could benefit from having more bits in the page table entries in which to store information, even for valid PTEs. So, they got them. Windows and, I believe, Linux both use those bits for a "working set index."
Searching for "working set index" and "page table entry" will find some evidence that this is true. For example, one of the reason codes for Windows bugcheck 1A means "the working set index in the page table entry is corrupted." Reliable evidence that AMD deliberately reserved those bits for that and similar purposes, at OS engineers' request, will be tougher or likely impossible to find.
But really, back to point one: Looking for a reason why "it's not the same as the machine bit width" is really misunderstanding the principle. It isn't supposed to be the same. There is no reason, other than a mistaken extrapolation from one example in recent history, to expect them to be the same. So I don't consider that it's needful to find an explanation for why they're not the same. The PTE format allows for a total of 52 bits of physical address, and that is that. Conversely, the point that there's no reason to expect them to be the same is not specific to x64 and so doesn't belong here. Jeh ( talk) 07:32, 3 June 2010 (UTC)
In Talk:X86-64#Why does the physical address space matter? several well-informed editors made convincing arguments that 32bit computers can access more than the 2^32=4GiB memory through various tables and address translations. But I am just a programmer, and the way it looks to me is that on 32 bit system I get a 32bit flat address space and cannot allocate over 2 or 3 or 4GB (depending on Windows or Linux flavor), my pointers are 32bit integers. My process simply cannot address more memory that 4GB. (Sure the hardware and the OS can create many flat addressable spaces each 4GB in size. Useful to the OS but not to my process.) On a 64bit system (hw+os) I do not have this limitation, my pointers are 64bit integers and I can go over the 4 GB limit, even in a single malloc to allocate a large array. So... isn't this a good reason to say in the article lead that 64bit allows to access more than 4GB memory? Jmath666 ( talk) 07:54, 9 June 2010 (UTC)
Agreed. Well, can you think of a way to put 4GiB somewhere in the article lede, please? Overcoming the 4GiB limit (of what user code can malloc) is the whole point of the 64bit transition to my clients. They just want to solve on cheap Windows or Linux machines the big engineering models they did on expensive Unix workstations, which went through the 64bit transition many years earlier. We just use the computers, rather than designing them. Thanks, Jmath666 ( talk) 08:58, 9 June 2010 (UTC)
HumphreyW, on the issue of undue weight if anything the information on the physical address space is lacking. Despite being one of the top three issues mentioned by articles I have read on the x86-64 at the moment the physical address space is given a single paragraph in the middle of the "Architectural features" section with no explanation given for why the physical address space matters. -- GrandDrake ( talk) 23:14, 3 June 2010 (UTC)
Well, I have since re-thought that position. In fact I think that what the article needs are referenced statements noting that increased physical address space beyond x86's 36 bits is really not a big deal for the vast majority of users.
First: A statement, no matter how well referenced, that RAM is faster than a hard drive is irrelevant to a description of x64's architectural changes; it rather belongs in an article comparing various data storage technologies. To put it the other way around - If it applies here then it applies just as well to the articles on PAE, on Itanium, and on other architectures with larger physical address spaces than their predecessors... going all the way back to 8088 vs. 8008 in the microcomputer field, and much farther than that in computing in general.
As for "consensus", consensus is represented by the previous state of the paragraph in question, which has been essentially stable for many many months. Yes, consensus can change, and for that, agreement is essential. You need to reach agreement with other parties for this change and I for one certainly am not in agreement that this material belongs here.
Second: a statement that "RAM is faster than a hard drive" (Really? You don't say? Imagine that!) is obvious to the point of being trite. Providing four different references to "defend" it, and then making essentially the same statement again, and using the same four references for the restatement, is being pedantic to the point of obnoxiousness; it's like making a statement that "trains roll better if they use round wheels instead of hexagonal" and then looking up a bunch of "references" to back it up. Even in an article where this statement needs to be made (perhaps, again, an article comparing various data storage technologies) these "references" are supporting a statement that no one is ever likely to challenge and therefore need not be supported by references at all. At most one reference would be completely sufficient... preferably to something like performance specifications.
Third: x64's vastly increased physical address limit is a moot point for the vast majority of users, except for the way Microsoft has chosen to support large RAM configurations, and the notion that we needed x64 to "break the 4 GB RAM barrier" is at best misleading. Allow me to explain.
Very few computers with x86 CPUs these days have CPUs that are not capable of PAE; netbooks are the only common exception. In other words, most x86 CPUs these days can address 64 GB RAM. They have had this capability since the Pentium Pro. Remember that many of the x86 "server" editions of Windows 2000 and 2003 Server do support more than 4 GB RAM - they do this via PAE, of course. [1]
It is only an implementation decision of Microsoft's to not support PAs more than 32 bits wide on their "client" versions of Windows (XP, Vista, and 7). [2]
The "4 GB RAM" limit of x86 is therefore largely a myth; it is a constraint imposed by the Windows OS, nothing more.
And the notion that we needed x64 at a hardware level to let us break this supposed 4GB barrier is therefore also a myth.
The way in which x64 does allow most users (those running Windows "client" OSs like Windows Vista or Windows 7) to use more than 4 GB RAM is very indirect: By using an x64 processor with a Microsoft x64 OS, you are using an OS which Microsoft has not "hamstrung" to 32-bit physical addresses.
The x64 physical address myth goes further than that. It is true that x64 allows RAM to go to 4 petabytes instead of the "mere" 64 GB permitted by PAE under x86, but really, 64 GB is already far outside of the amount that is likely to be put in most PCs anytime soon; or in fact, is even possible for installation, given chipset and DIMM slot limitations. I do happen to have a server class Xeon mobo here that can take up to 144 GB RAM with currently available DIMMs, but it is very much the exception, and even that would require 8 GB DIMMs, which are like hen's teeth and not supported by most consumer boards. The typical "desktop" or "deskside" motherboard has perhaps four or six DIMM slots supporting at most 4 GB DIMMs.
SO... In sum, I agree (even more than I did before) with HumphreyW: undue weight is even now being given to x64's 52-bit PA space. Yes, x64 allows users of Windows client OSs will be able to use more than 4GB of RAM for the first time. But they could have done that on x86 by using Windows Server OSs, or any of a number of Linux releases. Yes, x64 users will be able to use more than 64 GB of RAM... but for most applications, motherboards and DIMM configurations supporting even 64 GB are well in the future and more than 64 GB are farther away still. Jeh ( talk) 02:56, 8 June 2010 (UTC)
The statement that increased RAM helps "up to a point" is ambiguous and makes it sound like there is a hard limit. Since the phrase "which depending on the programs that are running can improve performance" is already conditional I don't see the need to add an ambiguous statement to the end of it. And different programs depending on different situations will vary in whether/how beneficial additional RAM would be (such as is the case with the 64-bit version of Photoshop). Instead of the article saying "which depending on the programs that are running can improve performance, up to a point" it says "which depending on the programs that are running can improve performance; though programs will have various points of diminishing returns." Would that be acceptable?
Also in regards to the references one links to what I believe is the wrong article since it doesn't have the quote that the reference uses and the information about the reference doesn't match up. The other reference is discussing the issue of the point of diminishing returns based on current price and performance for the Mailbox server role of Exchange Server 2010. -- GrandDrake ( talk) 01:28, 10 June 2010 (UTC)
Current AMD64 implementations support a physical address space of up to 248 bytes of RAM, or 256 TB (281,474,976,710,656 bytes). [3] This is a large increase over the limit imposed by x86 processors. In practice, the importance and meaning of this increased RAM capacity depends on a variety of factors, including the operating system chosen.
Since there is a disagreement on this point should x86 be used to refer to 32-bit x86 for processors? I ask since there should be a consistent term used when referring to 32-bit x86 in the article and at the moment the article has "x86", "32-bit x86", and "x86-32". Also should this apply to statements about programs where x86 is mentioned such as with "32-bit x86 executables"?
Every time a memory (p. or v.) size limit is mentioned there is text like this:
therefore can address up to 256 TB (248 or 281,474,976,710,656 bytes) of RAM.
It's repetitious in the extreme, very visually annoying.
Isn't there a better way to do this?
Idea: there are only a few different values actually used. Each of them could have its own note (and the notes and references section would be split into two, keeping the notes separate). So for example, 256 TB would appear as 256 TB[note 1], and note 1 would say "256 TB equals 248 or 281,474,976,710,656 bytes (approximately 280 x 1012." The current footnote template that says that since we're talking about semiconductor memory, these units are being used in their binary sense, would go in the notes section as well.
This might be good enough to start a new trend. Comments?
Jeh ( talk) 08:59, 10 June 2010 (UTC)
The AMD 64bit srchitecture specifically included the prefetch instructions in the interface, the early Intel 64bit processors didn't support this and at least a couple of first 64bit revs of Linux didn't run on Intel CPUs for that reason. Alan Cox ( talk) 22:03, 18 June 2010 (UTC)
One problem I notice in this article is that there is a bias in how the physical/virtual address space are portrayed. For comparison this is how the details of the 4 GB per process virtual address space limit is given:
"This is compared to just 4 GB (232 bytes) for the x86"
Not exactly a detailed explanation and compare that to how the physical address space limit is given:
"For comparison, x86 processors are limited to 64 GB of RAM in Physical Address Extension (PAE) mode,[7], or 4 GB of RAM without PAE mode." "In fact almost all x86 processors (from the Pentium Pro onward) can address up to 64 GB of RAM via physical address extension (PAE) a modification of the address translation scheme that is otherwise used.[7] Many x86 operating systems, including some versions of Windows Server, support this.[13][14][15] Provided that the operating system supports more than 4 GB of RAM, the increased physical addressing capability of AMD64 would therefore only be needed in systems requiring (and physically able to accommodate) at least 64 GB of RAM." "...even though x86 processors do not actually impose a 4 GB limit."
The 64 GB physical address space limit is noted clearly in several sentences while the virtual address space limit of 4 GB per process is not explained clearly in even one sentence. Attempts to clearly note the 4 GB per process virtual address space limit have been deleted. -- GrandDrake ( talk) 06:48, 19 June 2010 (UTC)
Note that the following two statements are unreferenced and repeat what earlier referenced statements had said:
"Provided that the operating system supports more than 4 GB of RAM, the increased physical addressing capability of AMD64 would therefore only be needed in systems requiring (and physically able to accommodate) at least 64 GB of RAM." "...even though x86 processors do not actually impose a 4 GB limit."
When I tried to delete them I was told that they were part of the narrative but at the moment that narrative looks biased by repeating information about one fact while ignoring a different fact. The average person who reads this article could easily come away from it thinking that they don't need x86-64 in regards to RAM since current 32-bit CPUs support 64 GB of RAM while never knowing that there is a 4 GB per process limit due to the 32-bit virtual address space. -- GrandDrake ( talk) 07:18, 19 June 2010 (UTC)
HumphreyW, on the issue of undue weight if anything the information on the physical address space is lacking. --GrandDrake (talk) 4:14 pm, 3 June 2010, Thursday (16 days ago) (UTC−7)
I have added the fact that it is possible for a computer to use more than 4 Gigabytes of RAM with a x86-64 CPU compared to a x86-32 CPU. This is one of the most commonly cited advantages I have seen in articles I have read on 64-bit CPUs and 64-bit operating systems but for some reason this was not mentioned in the lead section of the article.
-- GrandDrake ( talk) 21:27, 11 April 2010 (UTC)
The 4 GB VAS limit for the x86-64 legacy mode is not mentioned in the article. The AMD architecture specs is very clear that the VAS in legacy mode is limited to 32-bits. Since legacy mode is a part of the x86-64 architecture I think the 4 GB VAS limit in legacy mode should be mentioned at least once in the article. After consideration I agree that it would make the most sense to put that information in the legacy mode section. Are there any objections to including this information in the legacy mode section of the article? -- GrandDrake ( talk) 08:46, 24 June 2010 (UTC)
I have an issue with the statement about AMD losing the rights to manufacture x86 architecture chips. The original x86 patents are definitely expired now. Anyone can manufacture x86 compatible chips now. I haven't seen the agreement between AMD and Intel. That would be controlling, but I doubt the contract can enforce rights on expired patents.-- Celtic hackr ( talk) 17:19, 28 November 2010 (UTC)
"However, AMD64 still has fewer registers than many common RISC ISAs (which typically have 32–64 registers) or VLIW-like machines such as the IA-64 (which has 128 registers); note, however, that because of register renaming the number of physical registers is often much larger than the number of registers exposed by the instruction set."
Processors such ATOM without out-of-order execution engine, so does not have internal re-naming registers at all. Meanwhile, even though the Itanium architecture has 128 Gerneral registers, but implementations could contain much more registers than this without exposing to the user interface, similar with SPARC implementation with instruction windowing mechanism to access them. So the actual physical register number different among implementations, and should not be used to mention for some a specific architecture.
On the other hand, even though processor such as Intel Core 2 have potential much more physical registers to accelerate the internal out-of-order pipeline engine, because lack of huge architecture-level registers, most of compute operations are achieved with accessing the system memory. Meanwhile, Itanium has hugh architecture-level registers, some operations could be achieved without interfering external memory. The implementation register could not change this sematic behaviour. — Preceding unsigned comment added by 221.9.20.7 ( talk) 22:10, 11 June 2011 (UTC)
Is x87 code set still supported in native 64-bit Long Mode ? Or not ? The question is because x64's native SSE2 floating point instructions only can do with 8-bytes floating point. x87 could have more precision, even if with less speed. But is it possible at all ? It seems that Delphi XE2 Win64 compiler does not do x87. Is it inpossible due to hardware, or they just decided tosimplify things for themselves? 79.111.218.128 ( talk) 20:09, 30 September 2011 (UTC)
Unregistered editor 83.108.118.234 ( talk) edited the Linux section of the article as shown here, twice with the notably uncivil comment
Pretty sure the alledged [sic] 64-TB limit is bullshit.. afaik the linux64 kernel can handle close to 17 billion gigabytes of ram (aka ~16600000 TB))
If you're using "decimal billion" consistently that number would actually be 18 billion billion, that is, about 18.4×1018 bytes, i.e. 264.
However no operating system on x64 can support that much RAM (or that much virtual address space either), because the processors don't support it. Under the current architecture definitions these CPUs can provide a maximum of 256 TiB (248) of virtual address space, and 4 PiB (252) of physical address space (RAM); current implementations are further limited to 256 TiB of RAM (48 bits of physical address). That's all the bits that are implemented.
This is well described, with good references to the AMD docs, in the relevant sections of the article ("Virtual address space details" and "Physical address space details". There is also a very lengthy discussion of why this is so in the talk page archive here, section 33. (In response to someone else who didn't believe it.)
It is possible of course that a future change to the architecture could allow more than 48 bits of virtual address, or more than 52 bits of physical. But in the meantime, any statement regarding any OS running on x64 that claims implementation of more than 256 tebibytes of virtual address space, or of more than 4 pebibytes of physical address space (RAM), is simply wrong. It just isn't possible.
I'm removing the "dubious" template but leaving the "citation needed". Even though the IP's notion that a full 64-bit address space (either one) is supported by Linux64 simply cannot be true, a citation would still be nice for the limit that is claimed there. Jeh ( talk) 03:40, 3 October 2011 (UTC)
The AMD64 architecture defines a 64-bit virtual address format, of which the low-order 48 bits are used in current implementations.[1](p120) This allows up to 256 TB (248 bytes) of virtual address space. The architecture definition allows this limit to be raised in future implementations to the full 64 bits...
The AMD64 architecture enhances the legacy translation support by allowing virtual addresses of up to 64 bits long to be translated into physical addresses of up to 52 bits long. Currently, the AMD64 architecture defines a mechanism for translating 48-bit virtual addresses to 52-bit physical addresses. The mechanism used to translate a full 64-bit virtual address is reserved and will be described in a future AMD64 architectural specification.
The PAE-paging data structures support mapping of 64-bit virtual addresses into 52-bit physical addresses.
Is there an article about x32 ABI?-- 78.49.64.83 ( talk) 01:05, 1 November 2011 (UTC)
Frankly, I have never seen x86-64 outside Wikipedia. All software vendors seem to like to use x64. But how about verifiable facts? Which ones is used more often? x64 or x86-64? Fleet Command ( talk) 12:28, 21 June 2011 (UTC)
Is there a strong reason for mentioning that x86-64 and IA-64 are not the same thing? If we do mention that, then we should also mention that x86-64 does not also relate with Alpha, MIPS64, POWER/PowerPC 64-bit, and other important 64-bit architectures. It is either all or none.
Note: I saw someone revert my edit with a comment regarding that Windows can run both on x86-64 and IA-64. So what? Linux does too, and on all of the architectures mentioned above. World doesn't revolve around Windows, so we won't make useless remarks just because of it and generic consumer's ignorance. The second point of the person aforementioned was that IA-64 and Intel 64 are both made by Intel. It could be somewhat relevant if this article were about Intel 64, but it isn't; it is about x86-64 in general — an ISA subset common to both AMD64 and Intel 64, i.e. a vendor-neutral specification.
We already have a line by the header, which reads: "[...] For the Intel 64-bit architecture called IA-64, see Itanium." — That is quite enough. 95.220.134.217 ( talk) 19:35, 10 March 2012 (UTC)
To make it more objective I changed the title of the section "Legal issues of the AMD-Intel duopoly" to simply "Licensing issues". I also removed some speculation and unrelated information. -- GrandDrake ( talk) 06:16, 24 March 2012 (UTC)
Recent edits have mentioned max ram for Windows server 2006 and 2012. It looks to me based upon this:
http://blogs.technet.com/b/schadinio/archive/2011/02/23/windows-server-2008-2008-r2-max-memory.aspx
...that there is no one number we can put in the article. So, should we try to show the range of numbers, or just not mention Windows server 200X memory? -- Guy Macon ( talk) 17:29, 2 June 2012 (UTC)
Just saying. 136.169.53.84 ( talk · contribs) 01:15, 23 September 2012 (UTC)
Hi, I just came across this page from a link on the Windows Server 2008 page, since I wasn't sure about what the different abbreviations where for the architectures under Editions and System requirements. I thought x86 was always about 32-bit and x64 was 64-bit. This is how Microsoft labels their downloads at least. When I got to this page (in English) I got confused when just looking at the beginning where is says "x86-64 is an extension of the IA-32 32-bit version". An extension can be many things, so I got confused, but when reading another language ( Danish) I figured out that it actually is 64-bit. So my suggestion is to change the intro a bit and start telling that "this is 64-bit" and then go on. What do you think about that? If you agree, then just update it. I don't have a suggestion right now about how to write it. / PatrikN ( talk) 23:05, 15 November 2012 (UTC)
Added information on video game consoles that use x86-64. I was able to find information on how RAM is reserved for the Xbox One but was not able to find that information for the PlayStation 4. -- GrandDrake ( talk) 19:53, 3 June 2013 (UTC)
No. The reference given shows 128 TB usable for kernel space under Windows 8.1, but still only 8 TB in user space. The 128 GB in user space is only for Itanium versions. The needed phraseology is not straightforward because this is nevertheless using all 48 bits.
Perhaps a good wording would be this: Windows, prior to Windows 8.1, only populated 16 TB of the virtual address space. Jeh ( talk) 17:26, 20 January 2014 (UTC)
Ok, who's good with editing these SVG files? I would like to request that Image:AMD64-canonical--48-bit.svg and Image:AMD64-canonical--56-bit.svg be modified to include the text "(not to scale)" under the text "Noncanonical addresses".
If we were not trying to be so encyclopedic we could write "very much not to scale" instead. In the 48-bit diagram, the two canonical halves would be each 1/131072 of the total height. i.e. a tiny fraction of a pixel high! In the 56-bit picture the two halves would each be 1/512 of the total height, which still would not be an entire pixel on most screens... but it would be getting close to one.
Maybe we just need a "relative sizes not to scale" notation at the bottom of the whole thing. Jeh ( talk) 09:15, 22 January 2014 (UTC)
Even without the excessive lower-byte registers, the table is not working for me. It is not the case, for example, that there is one register of which EIP is the low 32 bits and RIP is the high. But that's what the table/diagram shows. I think all of the short forms should be removed in the short term. e.g. RIP would just show RIP. Jeh ( talk) 21:18, 14 February 2014 (UTC)
The Long mode section contained this
Real-mode programs and programs that use virtual 8086 mode at any time cannot be run in long mode unless they are emulated in software.
Which was deleted by Someone not using his real name ( talk · contribs) with a rather WP:POINTy edit comment.
I have restored it. Here's why: The method described in Virtual 8086 mode is
The addition of VT-X has added back the ability to run virtual 8086 mode from x86-64 long mode, but it has to be done by transitioning the (physical) processor to VMX root mode and launching a logical (virtual) processor itself running in virtual 8086 mode.
Westmere and later Intel processors usually[c] can start the logical processor directly in real mode using the "unrestricted guest" feature (which itself requires Extended Page Tables); this method removes the need to resort to [the nested] virtual 8086 mode simply to run some MS-DOS application.
See, you're still not running the real mode or virtual 8086 mode app under long mode! Of course you can run, as in start, such a program while using a long mode operating system... as long as you do it by creating a whole new virtual processor, which itself can run in the desired mode (Virtual 8086 or real mode). Heck, you could also have a second machine handy running an x86 OS and send the old binary to it for execution...
...But the restriction on running such programs in or under long mode is still there. As it says in the AMD doc (whose cite I just updated), page 11, note 3:
Long mode supports only x86 protected mode. It does not support x86 real mode or virtual-8086 mode.
I did acknowledge the possibility of getting around this restriction via VT-X, by appending this to the restored sentence:
However, such programs may be started from an operating system running in long mode on processors supporting VT-X, by creating a virtual processor running in the desired mode.
I believe this covers it, better than the original sentence did, and certainly better than the article did without that sentence.
However, I'm not sure what the big deal is about VT-X here. You could run a DOS app under x64 Windows (or, I believe, Linux) by using any of a number of virtual machine hosts—DOSbox having been specifically promoted for that purpose—long before VT-X existed. Jeh ( talk) 07:19, 18 February 2014 (UTC)
I think we should put an image in the lead section. Any ideas? The supercomputing cluster adoption chart looks best in its own section. Maybe we could use the logos of AMD64 and Intel64, or a photo of the first x86-64 processor (AMD Opteron). What would you suggest? Sofia Koutsouveli ( talk) 01:27, 20 March 2014 (UTC)
Hi. I'm thinking about low-resolution versions of "AMD64 Architecture Programmer’s Manual" and/or "Intel 64 and IA-32 Architectures Software Developer’s Manual", if that's allowed by the law. Dannyniu ( talk) 03:10, 14 June 2014 (UTC)
amd10h
was invoked but never defined (see the
help page).