Talk:X86-64/Archive 2

Archive 1

Archive 2

What is x86-64, IA-32e and Yamhill?

Is x86-64 the architecture name or a name pointing to implementations of Intel64 and AMD64?

If x86-64 is the name of an architecture, then is the IA-32 part of it? But why Operating Systems designed for x86-64 never use the IA-32 part, legacy mode? Well, in OS X 10.4, 10.5 and 10.6 kernel sits on the legacy mode, applications could run in long mode but without saying itself an x86-64 OS.

If x86-64 is the name points to a sort of implementations, which maintain the legacy support, that would make it clear.

The same question would in turn turns to the name AMD64 and Intel64. Exactly, is the legacy mode, IA-32, part of them, or just reserved for a duration helping maintain the legacy and transit in the implementations of their both?

Few documented details of Yamhill, and also rumored all the Prescott Pentium 4 already equipped with 64-bit support but just not enabled, or nobody knew how to. Is the name IA-32e the product of later Clackamas Technology or that Yamhill? If the latter, might IA-32e imply that the Intel's own 64-bit extension support might be a sub-mode alongside 32/16bit protected, rather than a completely switch-out like it in AMD64, leaving the OS kernel 32bit with the extension support for the potential 64-bit applications? Sorry for my fantasy guess. Janagewen (talk) 23:02, 7 September 2014 (UTC)

As the introduction to the article says:

Prior to launch, "x86-64" and "x86_64" were used to refer to the instruction set. Upon release, AMD named it AMD64.Intel initially used the names IA-32e and EM64T before finally settling on Intel 64 for their implementation.

The "Industry naming conventions" section of the article says

Since AMD64 and Intel 64 are substantially similar, many software and hardware products use one vendor-neutral term to indicate their compatibility with both implementations. AMD's original designation for this processor architecture, "x86-64", is still sometimes used for this purpose, as is the variant "x86_64". Other companies, such as Microsoft and Sun Microsystems/Oracle Corporation, use the contraction "x64" in marketing material.

IA-32 is the 32-bit version of x86, first implemented in the 80386. Both the AMD and Intel versions of x86-64 are supersets of IA-32; all x86-64 processors are capable of running IA-32 kernel-mode code and user-mode code. The kernel can run either 32-bit or 64-bit code, and either of those kernels can, if the developer chooses, run 32-bit or 64-bit user-mode code. x86-64 also supports running in 16-bit real mode, as well as all the other modes that IA-32 processors supported. I don't think either Intel or AMD have removed any of those older capabilities from their versions of x86-64, and I don't expect them to do so, as they probably don't want to have to worry about whether any code running on them still uses them. So, in that sense, IA-32 is part of x86-64, not just a temporary legacy capability.

OS X contained a 32-bit kernel capable of running 32-bit and 64-bit user-mode code in 10.4 and 10.5. In 10.6, it contained both 32-bit and 64-bit kernels (the one that was run depended on the hardware), and both of those kernels were capable of running 32-bit and 64-bit user-mode code. Newer versions of OS X have only the 64-bit kernel, but are still capable of running 32-bit and 64-bit code.

Extremetech claims that Intel had its own project to make a 64-bit version of x86, but that, as Microsoft had already agreed to support AMDs 64-bit x86, they told Intel that the Intel 64-bit x86 had to be compatible with the AMD 64-bit x86. There are a few differences between the Intel and AMD versions, listed in "Differences between AMD64 and Intel 64" section of the x86-64 article; as that section notes, some of the differences in early implementations were removed in later implementations.

If the pre-AMD64 Intel 64-bit x86 existed, I haven't seen anything that indicates whether the "Yamhill" name was used for it inside Intel, or, if so, whether Intel continued to use that name internally for their version of the (mostly) AMD64-compatible version. The names they used and use in public - as the "History of Intel 64" section of the x86-64 article says, they used "CT" (presumably for Clackamas Technology), "IA-32e", and "EM64T" before finally going with "Intel 64" - all referred to the AMD64-compatible version. So "CT", "IA-32e", "EM64T", and "Intel 64" all refer to the same thing - a 64-bit instruction set architecture capable of running 16-bit real-mode code, 16-bit protected-mode code, 32-bit protected-mode code ("IA-32" code), and 64-bit protected-mode code. The Intel x86-64 processors used by Apple, at least, were and are capable of running both 32-bit and 64-bit kernels with both 32-bit and 64-bit user-mode code; I don't remember what the tricks were that Apple used to do that, and don't know for certain whether 64-bit x86-64 processors from AMD can do that as well, but I wouldn't be surprised to hear that they can run a 32-bit kernel and 64-bit userland as well.

So that's probably not a difference between "IA-32e" and "AMD64". I seem to remember from an internal Apple presentation that Intel didn't believe that it was possible to run a 32-bit kernel and 64-bit user-mode code until Apple showed it to them, so I suspect that neither Intel nor AMD intended to support that. Once Apple started selling machines running the 64-bit x86 version of 10.4, Intel had to continue to support it if they wanted Apple to use their processors. AMD may not care unless they think they can convince Apple to start using their 64-bit x86 processors instead, and, at this point, Apple aren't shipping any machines that use a 32-bit kernel, so Intel may not care any more, either. Guy Harris (talk) 01:05, 8 September 2014 (UTC)

So million thanks for your reply, Guy Harris. I think I made some mistakes in this topic.

1. Mac OS X 10.4 Tiger is a 32-bit PowerPC OS, later versions adding support for 64-bit PowerPC Console Applications and 32-bit Intel processor.

2. Mac OS X 10.5 Leopard is a 32-bit Universal OS, with additional support for 64-bit applications for PowerPC64 and Intel64 processors.

3. Mac OS X 10.6 Snow Leopard is the apple's first 64-bit OS, running only on Intel processors, retaining support for 32 bit PowerPC Applications.

4. Mac OS X 10.7 Lion is the last OS retaining 32-bit kernel for Intel64 processors.

Before I thought OS X Tiger also supported 64-bit application for Intel64 processor, that is something I made confused. But I've also heard AIX 4.x support 64-bit application on 32-bit kernel, so I think for PowerPC architecture, that would be a common thing. But for Intel64 processor, that is quite rare, at least, as I know only Apple had gotten a try. For days, I also read something on Hackintosh on the Internet, so many hackers crack OS X kernel to adapt them onto AMD platform, even though they might hack the kernels with their patches, but I don't believe they would re-architecture for the XNU kernel. I saw many legacy AMD kernels could force hacked kernel sitting on legacy mode, applications on Long Mode. But in that environment, IA-32 applications would fail to start. That might say there might be something different between these two architectures, Intel64 and AMD64. I've also heard someone could perfectly host OS X on some virtual machines, as is known to me, none popular platform virtualizing software could cluster virtualize a guest OS, so that could tell Apple did not use VT to implement that "trick". So that way Apple went even further than Microsoft's WoW64. In my imagination, 32-bit kernel might provide essential OS mechanism to host 64-bit applications. Each time application loader aware of 64-bit application would be ready to run, it sets up lot of hooks onto the long mode to ensure 64-bit application would believe they are just sitting in 64-bit OS, when they requires the system all, those 64-bit hooks would grasp the processor from Long Mode back to Legacy Mode kernel to the real jobs. So in this situation a processor would switch between Legacy Mode and Long Mode much more frequently than usual. In OS X Leopard, only very few Applications, such as Chess provides 64-bit images, so most time the processor might never need to swift to the Long Mode. But in Snow Leopard, if Intel64 processor found at system initialization, all applications running within 64-bit mode. So in this situation, I confused myself, whether Compatibility Mode host the IA-32 applications, or the Legacy Mode host them? But I would prefer the latter. Even though Apple ever linked these two architectures (IA-32 and Intel64) together so seamlessly, but I would differentiate IA-32 with x86-64. Anyway, again, thank you very much for your reply. Janagewen (talk) 15:37, 20 October 2014 (UTC)

Yes, as far as I know, only Apple bothered to support a 32-bit kernel with 64-bit applications on x86-64 processors.

"I saw many legacy AMD kernels could force hacked kernel sitting on legacy mode, applications on Long Mode. But in that environment, IA-32 applications would fail to start." By "kernels" do you mean "OS X kernels", i.e. XNU, or do you mean kernels for other OSes, such as Linux? (I doubt that Windows or Solaris on a 64-bit processor would, when x86-64 first came out, have been offered without support for 32-bit applications, as almost all of the applications would have been 32-bit-only at that point.)

"That might say there might be something different between these two architectures, Intel64 and AMD64." There are some differences between them, as the article notes. I don't remember whether what Apple did to support 64-bit userland code on a 32-bit kernel depended on something that Intel did but AMD didn't do.

"So in this situation a processor would switch between Legacy Mode and Long Mode much more frequently than usual." Yes, that's what happened with non-K64 systems with OS X - every time a trap or interrupt, including a system call trap, occurred in a 64-bit application, the processor would have to switch back to 32-bit mode (as I remember, there were small 64-bit interrupt/trap handlers that would switch back to 32-bit mode and call the real 32-bit handlers.

"But in Snow Leopard, if Intel64 processor found at system initialization, all applications running within 64-bit mode." In Snow Leopard on machine with 64-bit processors, just as in Leopard on machines with 64-bit processors, and just as in Lion, Mountain Lion, Mavericks, and Yosemite (all those only support 64-bit processors), applications that have 64-bit code run in 64-bit mode and applications that don't have 64-bit code run in 32-bit mode. On some machines with 64-bit processors, but not all such machines, Snow Leopard would also run the kernel in 64-bit mode, unlike Leopard, which had only a 32-bit kernel. As more third-party kernel extensions, such as kernel-mode device drivers, were made 64-bit, and as machines got more memory so that they 1) could better support a kernel with 64-bit pointers and 2) could better use 64-bit mode to support that additional memory, later OS X releases ran the kernel in 64-bit mode on more systems. (The kernel on my Mountain Lion machine is 64-bit-only; I forget whether Apple switched to K64-only in Lion or Mountain Lion.) Guy Harris (talk) 17:55, 20 October 2014 (UTC)

"An Intel 64 architecture processor supports existing IA-32 software because it is able to run all non-64-bit legacy modes supported by IA-32 architecture. Most existing IA-32 applications also run in compatibility mode." on page Vol.1 2-21 of Intel® 64 and IA-32 Architectures Software Developer’s Manual September 2014, which might or might not imply that Intel 64 architecture and IA-32 architecture are two things, the only link is the Intel64 processor. Janagewen (talk) 07:50, 22 October 2014 (UTC)

x86-64 is an extension of the IA-32 architecture, which is, in turn, an extension of the 16-bit version of the x86 architecture. One could consider any extension of an instruction set from N bits to 2N bits to be a different architecture; one could view z/Architecture as being a different architecture from the ESA/390 architecture, and consider SPARC v9 as being a different architecture from the SPARC v8 architecture, and consider ARMv8-A as being a different architecture from the ARMv7 architecture, and consider the MIPS III architecture as being a different architecture from the MIPS II architecture, and consider the PA-RISC 2.0 architecture as being a different architecture from the PA-RISC 1.1 architecture. All of those extensions allow 32-bit user-mode code for the previous 32-bit version of the architecture to run.

Of those, ARMv8-A is the one for which the strongest case can be made, as it's significantly different - in 64-bit code, it has twice as many registers and doesn't have instruction predication. x86-64 isn't as different; it has twice as many registers but the instructions are largely the same. Guy Harris (talk) 17:51, 22 October 2014 (UTC)

I am  Done from this topic. Janagewen (talk) 00:09, 25 October 2014 (UTC)

Intel 64: Limited to 46 bits' worth of physical address space?

Janagewen made this edit, resulting in the following text - I've bolded the new bit:

* Early Intel 64 implementations only allowed access to 64 GB of physical memory while original AMD64 implementations allowed access to 1 TB of physical memory. Recent AMD64 implementations provide 256 TB of physical address space (and AMD plans an expansion to 4 PB), while some Intel 64 implementations could address up to 64 TB. Physical memory capacities of this size are appropriate for large-scale applications (such as large databases), and high-performance computing (centrally oriented applications and scientific computing.)

(46 bits gives you 64 TiB.) This is a very interesting find, and well-referenced, albeit to a primary source. It's actually contradicted, though, by later material in the very same set of documents. In Part 3, the "System Programmer's Guide", section 4.5, says:

IA-32e paging translates 48-bit linear addresses to 52-bit physical addresses.

But the document also frequently references a model-specific characteristic called MAXPHYADDR, the number of bits of physical address supported by the CPU. It is clear, for ex. on page 4-19, that this can never be greater than 52:

M is an abbreviation for MAXPHYADDR, which is at most 52; see Section 4.1.4.

but that it might be less. Section 4.1.1 doesn't say anything about it except that it can't be greater than 52. 2⁵² give you 4 PiB.

So, what should we do with this? It seems extremely clear to me that 52 bits is the architectural limit. Perhaps 46 bits is the most supported by any current processor. Or perhaps it's the least. Or maybe it was 46 bits on the first implementation. Or maybe it's an old bit of text that hasn't been updated in too long. We really have no way of knowing.

Is there a RS somewhere for a table of MAXPHYADDR values for various Intel processors? Or even a non-RS? (Not in our endless collection of articles like "List of Intel Core7 CPUs", there isn't.) I think this would be useful to help interpret the doc. Maybe we should just cite the architectural limit of 52 bits and note that implementations can support fewer? Jeh (talk) 09:23, 23 October 2014 (UTC)

Sorry, Professor Jeh, I think I should start a new section before I made a change here. I think the original writer about this sub-section might want to express the maximum physical addressing space for the current processors, or implementations, rather than potential architecture addressing capability. So I made this change. As is known to us, starting from AMD 10h (microarchitecture and implementation), 48-bit physical addressing capability has been introduced to most processors, but not all, such as famous AMD C-50 used in Netbooks, still addressing only up to 36-bit physical space. I think you know this much better than me. Intel 64 Processor is different from AMD 64 processors, they might have different background knowledge and future plans, so even though today, most popular Core i series processors could only address up to 36-bit physical space. Please allow my fantasy guess further on, the effective segment pointer for IA-32 architecture is 14 bits (including Local and Goble region) + 32 bits (base address) = 46 bits for potentially architecture specific logical addressing, and if without further paging, could in turn directly to the actual physical addressing. So that might be the reason why Intel implements current processors up to this limit. Professor Jeh, I am sorry, that guess might not be correct.

52-bit is the architecture potential addressing limit in this manual, but I think people would love to know the actual implementations' limit to customize their future platforms, so I change it. Maybe future implementations from Intel will exceed this limit, then please let then-time hobbies make that fix.

Professor Jeh, Thank you again. Janagewen (talk) 11:45, 23 October 2014 (UTC)

"52-bit is the architecture potential addressing limit in this manual" Then, as this article is about the architecture, is what it should say is the architectural limit.

"but I think people would love to know the actual implementations' limit" Then that should be a separate item from the architectural limit, in, for example, a table of the limits in particular AMD, Intel, and other processors.

"the effective segment pointer for IA-32 architecture is 14 bits (including Local and Goble region) + 32 bits (base address) = 46 bits for potentially architecture specific logical addressing, and if without further paging, could in turn directly to the actual physical addressing. So that might be the reason why Intel implements current processors up to this limit. Professor Jeh, I am sorry, that guess might not be correct." I suspect it's not correct - the limitations imposed in 32-bit mode on segmented virtual addresses aren't relevant to physical addresses, especially given that, in 32-bit mode, segmented virtual addresses get mapped by the segmentation hardware to 32-bit flat logical addresses, and those flat logical addresses are what get mapped to physical addresses by the paging hardware. Guy Harris (talk) 17:09, 23 October 2014 (UTC)

(Reply to this point by Password Saeba Ryo (talk) moved to the end of this section. Jeh (talk) 04:22, 27 December 2014 (UTC)

Also, this claim of 46 bits on IA32 is wrong. If you're in 80386 mode (required for the offset to be 32 bits) there is no "14 bits" from the segment descriptor, the SD base address is then also 32 bits. But these are not appended to each other, they're arithmetically added. So the final logical address (before translation through page tables) is 32 bits. This error was also in the x86 segmentation article; I just removed it. Jeh (talk) 20:07, 23 October 2014 (UTC)

There is nothing serious about what I made this stupid explanation, but I have to add that I don't say that segment pointer plus base address would draw a physical 46bit address in IA-32 architecture, and that would impossible draw that large address. But for this logical consistency, that would obvious give the reason why 46bits rather than 48bits or 52bits for Intel current implementations. As what Professor Jeh ever referred, this is only a "little calculus", and seriously don't waste your time on this annoyance, you have your own time to do your own biz, ok? This little change I made in the subsection "Older implementations", so that is just talking about something on implementation besides architecture. If the change what I made is incorrect, I made apologize, anyone is welcome to revert. And people from Intel might give the clear reason why, if they wish. Yeah, I have to say I am improper to be here. Sorry! Janagewen (talk) 23:11, 23 October 2014 (UTC)

When you write "= 46 bits for potentially architecture specific logical addressing", then the way the entire world talks about addressing, they think you mean an address is 46 bits wide; i.e. it could specify one of 2⁴⁶ locations in memory. Hence the correction. (By a similar logic we could say that in x86 non-PAE address translation we get 20 bits from CR3, 20 bits from the PDE, 20 bits from the PTE, and 12 bits from the original linear address, for 72 bits total!) Sorry, but this does not help at all in understanding the origin of any limits we're talking about here.

To the real issue: Part 3 of the Intel doc is very clear that 52 bits is the architectural limit. But I don't think we can just ignore this 46-bit limit. i.e. I'm not arguing for removal of your addition, Jan., I'm just trying to figure out how to write about it—how to put it next to the 52-bit limit and have them both make sense. But we don't really know what this 46-bit limit is. It is not a minimum implementation size because the text says "Intel64 [...] supports physical address space up to 46 bits." Could it be a maximum current implementation size? Well, it could, but "Intel64" is the name of the architecture, not of any implementation. I'm tempted to say it's simply an error in the manual, that it should have said 52, but we can't do that without good references. I just don't know what is the right thing to do with it, so I opened this topic. Maybe someone should ask Intel, but I doubt the query would reach anyone who truly Knows The Answer.

I think I'll ask in a couple of web forums. This in itself won't give RSs but maybe we'll get some pointers to some. Jeh (talk) 00:37, 24 October 2014 (UTC)

For the IA-32 architecture, there are at most 8192 local segment descriptors and 8192 global descriptors, which means 16384 descriptors in total, referenced by 14 bits on the segment registers, such as CS, SS and so forth. Each segment has maximum 4GiB space, could be represented and referenced by 32 bits. If all the segments never overlap each other, then logically there would be 64TiB (16K segments of 4GiB segments space) space could be addressing by 46 bits. And this 46 bits are the logical address in the IA-32 architecture and most potential addressing limit for the original IA-32 architecture. This, of course, was not implemented when it was introduced. Yamhill or initial IA32e might put a circle stop to it, but never had been released to the public, only rumors attracted computer science students, and I am one of them. Under Long Mode or current Intel IA-32e mode, this limit is gone with segmentations almost disabled or unavailable, but segmentation could also be used for compatibility mode programming, only never exceeds 4GiB space limit. So consideration only at this aspect, the 46-bits physical addressing limit for Intel 64 architecture is without question, and not possibly an error. But for others, especially stick to beliefs behind AMD64, it is obviously incorrect. In my opinion, AMD64 and Intel64 are two architectures too similar for readers to think they both the same, but just like their names, they must have the trend to go their separate ways in the future, only maintaining the essential compatibility. That is only my ideas about it, wrong is possible. But I have to say that my little revision might be incorrect too, as it says it is the limit of Intel 64 architecture for physical addressing, rather than implementations. So people if possible could find information from the current Xeon processors to find out the actual maximum addressing physical space they support. This is only a suggestion, I have no right or purpose to ask someone to do something. Just because I have no reach to those high end computers. I do apologize to everyone here and I am done from this topic. Janagewen (talk) 02:31, 27 October 2014 (UTC)

None of the characteristics of IA-32's segmented address scheme are in any way at all relevant to the amount of physical address that an IA-32 or x86-64 processor can access.

For IA-32, segmented addresses are translated, by the segmentation hardware, to a 32-bit linear address, which is then, without reference to the segmented address that generated it, translated to a physical address by the paging hardware. The size of the physical address that is generated depends solely on the characteristics of the paging hardware, which may only be able to generate 32-bit physical addresses if the hardware lacks the Physical Address Extension or PSE-36 features, or 36-bit physical addresses with one of those features.

For x86-64, the segmentation does not extend the size of the virtual addresses and, again, the maximum physical address depends solely on the characteristics of the paging hardware. Guy Harris (talk) 05:35, 27 October 2014 (UTC)

Janagewen writes:

For the IA-32 architecture, there are at most 8192 local segment descriptors and 8192 global descriptors, which means 16384 descriptors in total, referenced by 14 bits on the segment registers, such as CS, SS and so forth. Each segment has maximum 4GiB space, could be represented and referenced by 32 bits. If all the segments never overlap each other, then logically there would be 64TiB (16K segments of 4GiB segments space) space could be addressing by 46 bits. And this 46 bits are the logical address in the IA-32 architecture and most potential addressing limit for the original IA-32 architecture.

Sorry, but it just doesn't work that way. The result of adding a segment's base address to what is called the "displacement" from the instruction is always a 32-bit "linear" (Intel terminology) or "virtual" (OS terminology) address. It does not matter how many segment descriptors there are. It is true that a segment selector can pick one of 16Ki segments, but that does not mean there are 16Ki x 4Gi possible resulting linear addresses! No matter how many segment descriptors there are, the segment descriptor can only provide a base address from 0 through 0xFFFFFFFF, and the displacement can only be in the range from 0 through 0xFFFFFFFF; these are simply added together. Furthermore the segment must end at 0xFFFFFFFF or earlier (i.e. overflow beyond bit 31 is not allowed). So no matter which segment descriptor you pick, or what you store in it, the resulting linear address can only be in the range 0 through 0xFFFFFFFF. That's 32 bits, not 46.

Nor is it a question of "not implemented when it was introduced." Rather, no mechanism for asserting a linear address of more than 32 bits was ever defined for x86. To do that, either the segment descriptor base address field or the "displacement" in an instruction would have to hold than 32 bits. And in no version of x86, even a "not implemented" version, was either of those ever the case. Jeh (talk) 06:42, 27 October 2014 (UTC)

(The following was posted as a reply to Guy Harris's post of 17:09, 23 October 2014 (UTC). Moved here to better support continued discussion without.) Jeh (talk) 04:22, 27 December 2014 (UTC)

Then that should be a separate item from the architectural limit, in, for example, a table of the limits in particular AMD, Intel, and other processors. I think this is a good suggestion, and I paste a table at the bottom as a model. If this table could be merged into the main article, that would be much better and any correction to it is praised. Password Saeba Ryo (talk) 12:31, 26 December 2014 (UTC)

Processors	Physical Addressing Bit Width
Intel Pentium Pro/Pentium II/Pentium III/Pentium II Celeron/Celeron	36 bits
Intel Pentium 4/Pentium 4 Celeron/Pentium D/Celeron D	36 bits
Intel Core 2/Pentium Dual-Core/Celeron	36 bits
Intel Core i3/i5/i7/Celeron/Pentium	36 to 39 bits
Intel Xeon	36 to 46 bits
AMD Athlon 64/Athlon X2/Sempron/Sempron X2	40 bits
AMD Athlon/Athlon II/Sempron/Sempron X2	48 bits
AMD C-50	36 bits
AMD APU A4/A5/A6/A8/Athlon/Sempron	48 bits

Several points. One, this is an article about x86-64, and details on e.g. the Pentium Pro and others that are x86 only don't belong here. Nor do I think such specific details on every different implementation of x86-64 belong here; it seems to me that this article is at a more general level. Although I'm generally opposed to "parts catalog" type articles like List of Intel microprocessors or List of Intel Xeon microprocessors, as long as we have such articles, I do think this is information that could legitimately go in them. Note that we'd need references for each claim of fact. Jeh (talk) 04:22, 27 December 2014 (UTC)

So many thanks for your reply, Jeh. This is Janagewen. Where this table should put does not really matter, because there would always the place right for it. I recreated my another user account on Wikipedia.org just for finishing the discussions not done when I was blocked and my user page removed. This everything is ok and over to me, so anyways! Thank you again! Password Saeba Ryo (talk) 05:07, 27 December 2014 (UTC)

Redundant lists of implementations?

X86-64#AMD64 lists AMD's AMD64 processors at the beginning and also in the "Implementations" subsection. The same is true for Intel's Intel64 processors in X86-64#Intel64 and its "Implementations" subsection. Should one of each of those pairs be removed? Guy Harris (talk) 23:07, 14 February 2015 (UTC)

Hello! That's a good point, went ahead and deduplicated the content. Please check it out. — Dsimic (talk | contribs) 23:21, 14 February 2015 (UTC)

Looks good. Jeh (talk) 23:50, 14 February 2015 (UTC)

Would a list like the one that used to be at the beginning of X86-64#Intel64 be better in its "Implementations" subsection? The AMD list just goes by brand names; the Intel list breaks things up by a combination of brand names (Atom) and microarchitecture, but perhaps something such as

Intel's processors implementing the Intel64 architecture include the Pentium 4 F-series/5x1 series, 506, and 516, Celeron D models 3x1, 3x6, 355, 347, 352, 360, and 365 and all later Celerons, all models of Xeon since "Nocona", all models of Pentium Dual-Core processors since "Merom-2M", the Atom 230, 330, D410, D425, D510, D525, N450, N455, N470, N475, N550, N570, N2600 and N2800, and all versions of the Pentium D, Pentium Extreme Edition, Core 2, Core i7, Core i5, and Core i3 processors.

would work? Guy Harris (talk) 01:06, 15 February 2015 (UTC)

Hm, a more detailed breakdown we have in the article might actually be beneficial, but then again, the version you've proposed above reads much better. While thinking a bit more about it, your version would actually be better; for example, we'd also have to mention Xeon CPUs in the last bullet point, and that would be super redundant. So, I'd say you should go ahead and put your version into the article. — Dsimic (talk | contribs) 01:36, 15 February 2015 (UTC)

Done, but there's still redundancy in there; some of the material is historical and perhaps should be moved to the History section. Thanks for all your work on this! Guy Harris (talk) 01:55, 15 February 2015 (UTC)

Ah, I did nothing special, thank you for all your hard work! This edit should take care of separating most of the historical data and actual Intel 64 implementations. — Dsimic (talk | contribs) 02:52, 15 February 2015 (UTC)

Paging and x86-64

This is quite an interesting and important thing which might always confuse beginners trying to get in touch with x86-64 architecture. Some might confuse and mistake x86-64 architecture is an 48-bit architecture, no, that is absolutely wrong. x86-64 is a real 64-bit architecture, 64-bit(48-bit implemented) virtual address and 52-bit(48-bit implemented) physical address for AMD64, 64-bit(48-bit implemented) virtual address and 46-bit(fully implemented for latest Xeon processors) physical address for Intel64. 64-bit virtual/linear address is further paged into four levels, the top level is PML4, Page-map level-4, ranging from 9-bit (48-bit LA) through 25-bit (64-bit LA), leaving other three levels as 9-bit each for walking through a 4-KiB (12-bit) page. So if future x86-64 processors could fully implement 64-bit virtual address, this paging schema would not be changed. For AMD64 processor, under legacy mode, it could address up to 40 or 48-bit physical space when PAE enabled.

Another thing should also be paid attention to, the PAE capability is irrelative with it of IMC, Integrated Memory Controller. The actual maximum memory support is much less than it, but large physical space could enable devices to map their resources into this space, making expanded memory possible too. — Preceding unsigned comment added by 221.9.23.11 (talk) 02:09, 15 February 2015 (UTC)

Hello! Umh, sorry but I'm having slight difficulties understanding what are your actual suggestions on improving the article? Just as a note, talk pages should focus on article improvements; please see WP:NOTFORUM for further information. — Dsimic (talk | contribs) 02:56, 15 February 2015 (UTC)

No, the main article should also talk about something within this section. OK, guys, this is Janagewen! Would you please lock all the IP addresses within my reach. Then I would not be able to visit Wikipedia.org website. If you could help me lock all the IPs, I would say thank you to you guys! 221.9.23.11 (talk) 03:08, 15 February 2015 (UTC)

Nobody is claiming it is a 48-bit processor or that it is not a "real 64-bit architecture". However, translation of more than 48-bit virtual addresses will almost certainly involve a change to the page table structure. I would even suggest that anyone who suggests otherwise does not really understand the ramifications of what they're claiming.

The PML4 at present can only be 512 entries long, as it is indexed by only 9 bits (bits 39 through 47 of the v.a.). Now let's suppose we allow 64 bits of v.a. with no change to the page table hierarchy. Then the index value to the PML4 table would be 25 bits wide (the 9 bits currently implemented, plus 16 more). To allow all possible index values the PML4 table would therefore have to be 2²⁵ or 32x1024² entries long. Since each entry is eight bytes this would occupy 256 MiB. That's 256 MiB of not-pageable, physically contiguous RAM. That seems like rather a large memory requirement, even with modern multi-GiB RAM configurations, especially since all three major OSs that run on x86-64 use a different PML4 table for each process. With just 16 processes you would need 4 GiB of RAM just for the processes' PML4 tables. I don't think that is a viable approach.

No, the most reasonable way to implement more bits of VA would be to add more levels to the page table hierarchy, exactly analagous to how the PML4 table was added to the three-level PAE design. The most obvious design would have a 5th-level table (PML5?) indexed by bits 48 through 56 of the VA, and a 128-entry 6th-level table, with its PA in CR3, indexed by bits 57 through 63. (Maybe when they do that they can get rid of the silly special names for each level in the hierarchy and just call them page tables levels 1 through 6!) Jeh (talk) 10:34, 15 February 2015 (UTC)

No, completely no! There would be no PML5 or PMLn. — Preceding unsigned comment added by 192.154.200.6 (talk) 22:58, 28 September 2015 (UTC)

Why not? It would certainly work. How do you know this with such certainty? Jeh (talk) 05:26, 1 October 2015 (UTC)

... actually it doesn't matter. All of this is speculation. WP doesn't publish editors' speculation. I'll be archiving this section as irrelevant to improving the article. Jeh (talk) 05:26, 1 October 2015 (UTC)

Hello, 192.154.200.6. There is only PML4, and whether there would be PML5, we are not so sure at this moment. Hello, Jeh. We have no ideas whether it would certainly work. Do you have any book or document to prove your words? EhietGeht (talk) 06:15, 1 October 2015 (UTC)

Please. This is a standard technique for implementing sparse arrays, taught in every data structure class, implemented in many many cases. Specifically for address translation, some older processors (like the VAX) use a single level of PT lookup. x86 without PAE uses two levels. x86 PAE uses three levels. x64 long mode, aka IA-32e paging by Intel's naming, uses four levels. There is no reason to think that the technique would magically stop working at level five or six. I'm not claiming it's the best way to implement 16 more bits of virtual address (there might be other methods that would scale better) but yes, it would certainly work. It already does. And it would be a simple set of changes to existing code. Jeh (talk) 05:20, 2 October 2015 (UTC)

Hello, Jeh. We have no information on that right now, and we do not speculate any possibility. EhietGeht (talk) 22:30, 2 October 2015 (UTC)

Beg pardon, but we don't include speculation in articles. This is a talk page. I was responding to a claim by 221.9.23.11 that x64's current address translation scheme could support 64-bit virtual addresses as x64 is currently defined, specifically

"So if future x86-64 processors could fully implement 64-bit virtual address, this paging schema would not be changed. 221.9.23.11 (talk) 02:09, 15 February 2015 (UTC)"

That was, and remains, a false claim. My suggestion that more levels could be added to the PT hierarchy was an example of the sort of thing that would have to be done for x64 to implement 64-bit VAs. Talk pages are for discussing improvements to the article, but that "restriction" is interpreted quite broadly. It does include discussion of why an editor's claim is wrong. It is much better to head off such things before they get into articles. Jeh (talk) 22:49, 2 October 2015 (UTC)

btw, thank you for using regular talk page formatting! That did not go unnoticed. Jeh (talk) 22:49, 2 October 2015 (UTC)

Hello, Jeh. We do not have any idea about that claim, and we do not either speculate its correctness. EhietGeht (talk) 23:03, 2 October 2015 (UTC)

On the contrary, we have a perfectly good "idea" about the claim. The fact that the paging scheme defined for x64 is limited to 48-bit virtual addresses is exactly described in both AMD and Intel's docs (as profusely linked already). The diagrams of address translation in those documents clearly show that bits 48 through 63 of the VA do not participate in address translation in the current scheme. Ergo, to translate even one more bit of VA, let alone 16 more bits, the scheme would have to change. QED.

As for what "we do not" do, you are free to refrain from what you regard as "speculation." For myself, I disagree with that characterization of my responses, nor does "WP does not publish speculation" strictly apply to talk pages. I acknowledge that you have a different opinion. Let's leave it at that, please. Jeh (talk) 23:24, 2 October 2015 (UTC)

Hello, Jeh. I have to make clear that everything you mentioned here or someone else could only be a speculation. Even let me to speculate your mentioned PML5 or PMLn are far more practical than what we expect. At least at this moment, we do not want to waste that huge cost for additional paging level(s). So we do not have any word around that presumption. EhietGeht (talk) 00:27, 3 October 2015 (UTC)

Hello, 221.9.23.11. We have no ideas that if future x86-64 processors could fully implement 64-bit virtual address, this paging schema would not be changed, because there is no documents to prove what you said. But the actual maximum memory support is much less than it is incorrect, the physical memory could be supplemented with a second processor attached on the Hyper Transport Bus, the MPS BIOS would map the physical memory space to these different physical regions. So no matter 40-bit or 48-bit physical address space could possibly be reached without any doubt. EhietGeht (talk) 00:49, 3 October 2015 (UTC)

Shall We Further Extend the Section Intel 64 History?

“ When engineers at Intel started with a “clean sheet of paper” in 1991, it was no surprise that two schools of thought emerged: one to extend CISC IA-32 instructions to support 64-bits, and another to introduce a cleaner RISC style instruction set with the 64-bit support (while maintaining the old instructions for compatibility). While we settled on the RISC approach for a new 64-bit architecture, the attractive idea of extending IA-32 for 64-bit addressing was revisited several times within Intel. It turns out that, for all the marketing charm that a simplistic idea like adding 64-bit addressing to IA-32 holds, in reality that approach would not yield the long-term value we needed. We didn’t figure it out right away, but the RISC approach faced the same reality. ”

The above words are directly referenced from Foreword of Itanium Architecture for Software Developers by Walter Triebel, Intel Press 2000, ISBN: 0970284640. Focusing on the date, 1991, possibly guesses would easily be put to consideration of Intel's own 64-bit version of IA-32 more than a decade before Yamhill rumoured. 175.17.63.223 (talk) 01:52, 15 September 2015 (UTC)

I think we would need something a lot more specific than this. And there are a lot of problems with it, even just as it is now. For one thing, anyone considering extending x86 to 64 bits is clearly not starting with "a clean sheet of paper"! Also, this narrative is belied by our own article on Itanium, which states that Itanium development began at HP with "investigations" in 1989, and that HP's partnership with Intel on what was to be called Itanium didn't happen until 1994. Now, hmm... the article that text references actually claims the latter date is 1993. But still, that puts some doubt into the 1991 claim. Or at least into exactly how specific were these two "schools of thought" at Intel in '91. What exactly happened at Intel in 1991, or at any of the later "revisits"? Did someone just write "x86 extended to 64 bits" on a whiteboard once or twice and each time say "nah, that's stupid" and cross it off? Or did they investigate the concept without defining it in much detail? Or did they (during any of those visits) go as far as spec'ing out a proposed 64-bit ISA that would be recognizable as an ancestor of Intel64? If not the latter (and, of course, we'd need good solid references) then I don't think it belongs in a history of Intel 64. Maybe in a more-generic history of 64-bit computing? Jeh (talk) 06:13, 4 October 2015 (UTC)

x64

It should be clearly noted that the term "x64" is wrong and only used by two companies. The correct terms used by Intel and AMD are "x86_64" and "amd64". 193.166.70.166 (talk) 12:51, 30 September 2015 (UTC)

Incorrect on several points, I'm afraid, particularly the notion that "x64" is somehow "wrong". It isn't specific to either Intel or AMD but that doesn't make it wrong.

“ x64 is a generic name for the 64-bit extensions to Intel's and AMD's 32-bit x86 instruction set architecture (ISA). AMD introduced the first version of x64, initially called x86-64 and later renamed AMD64. Intel named their implementation IA-32e and then EMT64. ”

That's from Introduction to x64 Assembly, an article at intel.com. Jeh (talk) 13:46, 30 September 2015 (UTC)

Hello, 193.166.70.166, thank you for figuring out x64. But your description is incorrect. Intel uses IA-32e while AMD uses AMD64 in their official documents. So many software have already used x64, x86-64 and x86_64 to refer to this instruction set. As to the main article, because it is written by kids or hobbies rather than professionals or experts on computer science. So we could not have a fair judgement. But you are welcome to help improve it. EhietGeht (talk) 06:09, 01 October 2015 (UTC)

Intel now uses Intel64 as the marketing name, but still uses "IA-32e" internally. See section 4.5 of Intel® 64 and IA-32 Architectures Software Developer’s Manual, where they describe "IA-32e paging", but then look at the title on the cover! Jeh (talk) 04:57, 2 October 2015 (UTC)

---

1. Where does x64 come from?

Windows XP 64-Bit Edition for 64-Bit Extended System was the very first product for AMD64 architecture released in September, 2003, and it was later renamed to Windows XP Professional x64 in late 2004.

Incorrect. What Microsoft shipped in 2003 was Server 2003 for Itanium. x64 versions of Windows XP and Server 2003 didn't RTM until March 2005. I believe the term "x64", as an obvious parallel to "x86", had been used earlier. "x64" is certainly all over a lot of Linux distro file names. Jeh (talk) 22:53, 9 October 2015 (UTC)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

You will not find an "official" date for the "x64" term from Intel or AMD because to neither of them is it an official term. Forums are user-contributed content and are not considered reliable sources on Wikipedia. Re Windows versions, please see Timeline of Microsoft Windows. Jeh (talk) 02:46, 10 October 2015 (UTC)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

I don't have a source for the origin of the term "x64". (Which is why I said "I believe...") Perhaps you could find one. We know that both Solaris and Oracle use the term "officially" but I haven't been able to find a RS for their first use (and Sun/Solaris is now part of Oracle). It is clear the XP and Server 2003 for x64, which RTMd in 2005, were an official use, but my point is simply that the term's first use as part of a Microsoft product name cannot be used as proof that Microsoft invented the term, so we can't make that claim. Jeh (talk) 04:03, 10 October 2015 (UTC)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

Nope. If you'll notice, I voiced an opinion contrary to 193.166.70.166's. But by all means, if you think that, create an WP:SPI. I will be happy to see this speculation about me definitively dismissed. Jeh (talk) 06:07, 10 October 2015 (UTC)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

The wording 64-bit instruction set of x86 processor would be very confusing. To many, if it's an "x86 processor" then it isn't 64-bit. Note for example that 64-bit Windows stores 32-bit executables in \Program files (x86). If one interprets "x86 processor" to mean a 32-bit processor, which is a very common interpretation, then such a processor flatly cannot have a "64-bit instruction set". On the other hand, a 32-bit instruction set can most certainly be changed, enhanced, extended, etc., to include 64-bit support, and that instruction set implemented by a 64-bit processor. Jeh (talk) 22:40, 9 October 2015 (UTC)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

Well, no, they wouldn't have said exactly that... since "x86", being non-manufacturer-specific, is not an AMD official term (nor an Intel official term).

I didn't say "x86 processor" is purely a 32-bit processor. I said it is widely understood to be that.

Previously you noted that in an Intel book you found the text "extend CISC IA-32 instructions to support 64-bits," and now here you are claiming that the result of such an effort should not be called a "version" of the IA-32 (or, generically, x86) instruction set. In fact, these two wordings are perfectly compatible with each other.

The full details are these: An x64 processor in legacy mode (which is how they come up after a reset) supports the 32-bit x86 instruction set, with the added mechanism to switch to long mode. Once in long mode the processor then supports either the Intel64 or AMD64 instruction set depending on manufacturer (these are nearly identical), generically called the "x64" or "x86-64" instruction set. This includes "compatibility mode", a 32-bit mode available "within" long mode, which provides practically the entire 32-bit x86 instruction set to applications.

But that's a really long description, you don't put such in the article lede. For the article lede, "64-bit version of x86 instruction set" is an easy way to introduce the concept and perfectly suitable for the lede; the details are for the article body. Jeh (talk) 03:03, 10 October 2015 (UTC)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

As you said: AMD documents state " "The AMD64 architecture is a simple yet powerful 64-bit, backward-compatible extension of the industry-standard (legacy) x86 architecture." That's a "horse's mouth" source. That and the statement you're arguing against are semantically equivalent; we do not need to find sources for exact phrasing and word choice. If you're quibbling that "version" is something different enough from "extension" to need another source, you are simply wrong; you are arguing over a distinction that does not make a difference. (Most "extensions" can indeed be called "versions", but not every "version" is an "extension.") Jeh (talk) 04:12, 10 October 2015 (UTC)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

The phrase from the AMD doc that you previously quoted is completely sufficient reference. The points you raised such as elimination of segmentation (um, well, but segments are still operational in compatibility mode! They have to be, for 32-bit protected mode code to work right) and additional registers are entirely compatible with the word "version". I think the real problem is that you do not understand the full scope of meanings to which "version" can refer: It can include things added, things left out, existing things changed. If anything we could argue that the AMD doc's use of "extension" is misleading (one of your favorite words) because if we remember that segmentation is not present in long mode, the long mode architecture cannot be said to be a pure "extension", since it left some things out! Bah. There's no problem with the existing text. Jeh (talk) 04:59, 10 October 2015 (UTC)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

Yes, I'm welcome to agree with Jeh 100% and Janagawen 0%. x86 is a family of instruction sets (16-bit x86, 32-bit x86 or IA-32, 64-bit x86 or x86-64), just as MIPS is a family of instruction sets (MIPS I, MIPS II, MIPS III, MIPS IV, etc.) and System/3x0 is a family of instruction sets (32-bit-with-24-bit-addressing System/360, 32-bit-with-24-bit-addressing System/370, 32-bit-with-31-bit-addressing System/370-XA, 64-bit z/Architecture), and so on. Guy Harris (talk) 06:56, 10 October 2015 (UTC)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

There exists a family of instruction set architectures that includes 16-bit x86 (as implemented in the 8086/8088, 80186/80188, and 80286), 32-bit x86 (as implemented in the 80386 and all later 32-bit processors), and 64-bit x86 (as implemented in the Opteron and all later 64-bit processors). 32-bit x86, or IA-32, was a backwards-compatible extension of 16-bit x86, and 64-bit x86, or x86-64, was a backwards-compatible extension of 32-bit x86. That family is what the x86 page covers.

Intel even spoke of "32-Bit Extensions of the Instruction Set" in their "Introduction to the 80386" document, saying

With the 80386, the 86/186/286 instruction set is extended in two orthogonal directions: 32-bit forms of all 16-bit instructions are added to support the 32- bit data types, and 32-bit addressing modes are made available for all instructions referencing memory. This orthogonal instruction set extension is accomplished having a Default (D) bit in the code seg- ment descriptor, and by having 2 prefixes to the instruction set.

so IA-32 was just like x86-64 in that regard, and there's no reason to treat them differently. The only thing that led to "x86" being used when "IA-32" was what was meant was that, when x86-64 arrived, most x86 processors were 32-bit rather than 16-bit.

There needs to be some way to refer to the entire family of instruction sets, starting with the 8086 instruction set and going all the way to the instruction set implemented by Skylake processors. If you have a better suggestion for a single name for that entire family, please suggest it; x86-64 would then be the 64-bit version of that instruction set, or the 32-bit member of that instruction set family, just as IA-32 would be the 32-bit version or member. Guy Harris (talk) 03:41, 11 October 2015 (UTC)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

Do you also suggest that "32-bit instruction set of an x86 processor" is a better description of IA-32 than "32-bit version of the x86 instruction set"? If not, why not? I don't think the fact that "x86-64" begins with "x86" is enough of a reason. Guy Harris (talk) 04:56, 11 October 2015 (UTC)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

No, x86-64 isn't any more special than IA-32. It's distinct from IA-32, but that's because IA-32 is a 32-bit instruction set, and x86-64 is a 64-bit instruction set; both are in the same family as the original 16-bit 8086/8088/80186/80188/80286 instruction set, namely the x86 family. That original instruction set was extended to 32 bits with IA-32 and IA-32 was extended to 64 bits with x86-64.

x86-64 isn't a replacement for Itanium, it's an attempt by AMD to compete with Intel in the 64-bit market. AMD's original press release emphasizes the "you can switch to 64-bit computing as necessary, rather than having to make a big change right now" aspect of x86-64. Intel and HP had tied up IA-64 with patents so that AMD couldn't implement it themselves. As AMD's x86-64 processors implemented x86-64 and IA-32 with the same circuitry (x86-64 being a compatible superset of IA-32), their processors were not only fast 64-bit processors, they were also fast 32-bit processors running IA-32 code - unlike the original IA-64 processors, whose IA-32 implementations were slow. So x86-64 processors could be put into ordinary PCs running 32-bit code, especially starting with the 64-bit Athlons, whereas IA-64 processors couldn't. It was intended from the beginning to be an extension of IA-32, so that x86-64 processors could be used instead of IA-32 processors, even running 32-bit-only code, just as IA-32 was intended from the beginning to be an extension of 16-bit x86, so that IA-32 processors could be used instead of 16-bit x86 processors, even running 16-bit-only code. So it's just like IA-32 in that way, and it's valid to refer to it as the 64-bit version of the underlying instruction set, just as IA-32 is the 32-bit version.

x86-64 never was "completely new" in the way that IA-64 was; it was a compatible extension, rather than an incompatible new instruction set like IA-64. The AMD press release says "AMD plans to extend the x86 instruction set to include a 64-bit mode", just as Intel said that "With the 80386, the 86/186/286 instruction set is extended in two orthogonal directions".

Intel don't call Intel 64 "a 64-bit version of IA-32", because it's a 64-bit member of the x86 family of instruction sets; it's not a 64-bit version of IA-32, because IA-32 is the 32-bit member of that family. It's a 64-bit version of x86, just as IA-32 is a 32-bit version of x86. AMD speak of it as an extension to x86, similar to the extension to 32 bits (and to an extension from 8 bits to 16 bits, but it's not clear what they're talking about there - the 8086 and 8088 were 16-bit processors, although the 8088 had an 8-bit external bus) in another press release.

So x86-64 is an extension of the x86 architecture to support 64-bit computing, just as IA-32 was an extension to support 32-bit computing.

And as for "alternative choices", there were no alternative compatible choices to x86-64, either, and if you consider incompatible choices, there were alternative choices to IA-32, such as 68k. Yes, IA-64 processors could run IA-32 applications, but not very well.

As for "the 16-bit architecture evolves into this IA-32 architecture", IA-32 evolved into x86-64, just as 16-bit x86 evolved into IA-32.Guy Harris (talk) 09:51, 11 October 2015 (UTC)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

"I mean the successors of the IA-32 architecture, Itanium and AMD64". Itanium wasn't a successor in any technical sense; the two instruction sets are radically different. Intel intended that it replace IA-32 from a marketing point of view, but assembler programmers and compiler writers will be able to use next to nothing of their understanding of IA-32 when writing software for IA-64. AMD64, however, was a backwards-compatible extension of IA-32, adding the REX prefix to allow access to additional GPRs, IP-relative addressing modes, and 64-bit operands, and another operand-width bit in segment descriptors; in legacy mode, the values used by REX prefixes are interpreted as single-byte increment-register and decrement-register instructions, but, in long mode, they're interpreted as REX prefixes. That means you have to use multi-byte versions of register increment and decrement instructions in long mode, but that's the only incompatibility between IA-32 and x86-64 in long mode.

So x86-64 looks, with the exception of the single-byte increment-register and decrement-register instructions, like "IA-32 with more stuff added on"; that's more like "English in 1988", which lacked such important features as the noun "selfie" and the verb "google", vs. "English in 2015", with those additions, than like Spanish and Latin. No radical change there, just change like the 16-bit x86 instruction set to IA-32, with the addition of additional addressing modes, an operand-width bit in segment descriptors, etc..

"Spanish and Italian languages are evolved from Latin language" Without "backwards compatibility" - for example, both Spanish and Italian have significantly simpler grammars than Latin. x86-64 is backwards-compatible with IA-32, so that's not a good example - it's more like the difference between ARM A32 and A64, where the instructions changed in an incompatible fashion (for example, most of the conditional execution capabilities were removed in A64). IA-32 to x86-64 is more like the evolution from SPARC v8 to SPARC v9, or from System/390 to z/Architecture, or from PA-RISC 1.1 to PA-RISC 2.0, or from MIPS II to MIPS III, or from 32-bit PowerPC to 64-bit PowerPC.

And calling x86-64 the 64-bit version of x86 doesn't do anything to make people think it's another architecture from x86 - in fact, it more strongly emphasizes that it's a version of x86. Not all x86 processors support x86-64, so it's not the "64-bit instruction set of an x86 processor"; only 64-bit x86 processors support it, just as only 32-bit and 64-bit x86 processors support IA-32. x86-64 is a superset of IA-32, just as IA-32 is a superset of 16-bit x86; an x86 processor could:

• support 16-bit x86 without virtual memory (8086/8088, 80186/80188);

• support 16-bit x86 with segmented virtual memory (80286);

• support 16-bit x86 and 32-bit x86 with segmented and paged virtual memory (80386 and later IA-32-only processors);

• support 16-bit x86 and 32-bit x86 with segmented and paged virtual memory and 64-bit x86 with paged virtual memory (x86-64 processors). Guy Harris (talk) 18:24, 11 October 2015 (UTC)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

And IA-32 is different from 16-bit x86. Speaking of x86 as a "consistent architecture" is a bit bogus, given that it's an architecture with stuff added through a variety of hacks. I don't consider the lack of segmentation in x86-64 to render it somehow not "the 64-bit version of x86" - the 16-bit version has segmentation (which was used significantly), the 32-bit version has segmentation (which was used a lot less), and the 64-bit version doesn't have it in long mode, but still has it in legacy mode. I also don't consider the inability to access the upper 32 bits of the first 8 64-bit GPRs in 32-bit mode to render it not "the 64-bit version of x86". Most of the RISC instructions sets that were extended from 32 bits to 64 bits did so without a mode bit, so there's no notion of "long mode" vs. "legacy mode", and any code can get at all 64 bits of the GPRs on a 64-bit processor. What's different about x86 is that, in real mode, there's no segmentation, so there's no segment descriptor to have a default operand size, and real mode has to be compatible with real mode on 16-bit x86 processors, so the REX prefixes can't be used (they're interpreted as single-byte increment/decrement register instructions), so you can't have 64-bit operands in real mode. So x86-64 isn't as clean an extension of 32-bit x86 to 64 bits as the 64-bit versions of RISC architectures are extensions of the 32-bit versions of those architectures to 64 bits, but it's still an extension of that sort. Guy Harris (talk) 00:20, 12 October 2015 (UTC)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

A nitpick: Segmentation isn't completely absent in long mode. In compatibility mode, which is how 32-bit code runs under a long mode OS, segmented addressing is still there in all its former glory and detail. It rather has to be, or else a great deal of existing 32-bit code (any instruction that uses an explicit segment reference, any code that accesses segment descriptors, any code that writes and reads the segment registers and expects them to function) wouldn't work. So you can't say that segmentation is missing from long mode. Compatibility mode is part of long mode, after all.

Even in 64-bit mode (the other part of long mode), the FS and GS registers still exist and do support non-zero base addresses. (And of course if we're being really thorough we have to mention the four remaining bits of the CS register!) Granted this is nothing like a full implementation of segmentation, but it does mean that you can't say that segmentation is gone completely even from 64-bit mode. Jeh (talk) 06:34, 12 October 2015 (UTC)

As far as I'm concerned, "x86" is the family of instruction sets that includes the 16-bit version without an MMU, the 16-bit version with an MMU, the 32-bit version, and the 64-bit version, so the "difference between x86-64 and x86" is that x86 is the family and x86-64 is the 64-bit member of the family.

x86 has several modes:

• real mode, which is implemented by all four members of the family - including the 64-bit version, where it's a submode of legacy mode;

• 16-bit protected mode, which is implemented by the 16-bit version with an MMU, the 32-bit version, and the 64-bit version as a submode of legacy mode;

• 32-bit protected mode, which is implemented by the 32-bit version and the 64-bit version as a submode of legacy mode;

• virtual 8086 mode, which is implemented by the 32-bit version and the 64-bit version as a submode of legacy mode;

• long mode, which is implemented by the 64-bit version, with 64-bit and compatibility submodes.

Not all of the features of a version of the architecture are accessible from all modes supported by that version of the architecture. You can't do virtual-memory segmentation, or paging, in real mode. You can't do paging in 16-bit protected mode in the 16-bit version with an MMU, although you can run 16-bit protected-mode code in 32-bit protected mode, with or without paging. You can't support linear addresses larger than 32 bits in the 32-bit version. None of this makes x86-64 anything other than the 64-bit version of x86, as far as I'm concerned, and I don't see "64-bit instruction set of x86 processor" as being an improvement over "64-bit version of the x86 instruction set". For one thing, not all x86 processors support a 64-bit instruction set, only the ones that support the 64-bit version do. An "x86 processor" is just a processor that supports some version of the x86 instruction set, just as a MIPS processor is a processor that supports some version of the MIPS instruction set (32-bit or 64-bit), and a SPARC processor is a processor that supports some version of the SPARC instruction set (32-bit or 64-bit), and a PowerPC/Power ISA processor is a processor that supports some version of the PowerPC/Power ISA instruction set (32-bit or 64-bit), and a "System/3x0", or whatever it should be called, is a processor that supports some version of the System/3x0 instruction set (which includes System/360, System/370, System/370-XA, System/370-ESA, System/390, and z/Architecture, so it includes 32-bit with 24-bit physical addresses, 32-bit with 24-bit virtual addresses, 32-bit with 31-bit virtual addresses, 32-bit with multiple address spaces each with 31-bit virtual addresses, and 64-bit with multiple address spaces each with 64-bit virtual addresses; that family of instruction sets also has multiple modes, and not all of the features of a version of the architecture are accessible from all modes, and the behavior of instructions is mode-dependent, e.g. the uppermost 8 bits of addresses are ignored in the 24-bit address modes and the uppermost bit of addresses is ignored in the 31-bit address modes). Guy Harris (talk) 06:47, 12 October 2015 (UTC)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

Discuss all you want, but I can't agree with you, and, unless there's a consensus for "64-bit instruction set of x86 processor", whatever that might mean, I'll revert changes that use it in the main article. Guy Harris (talk) 07:20, 12 October 2015 (UTC)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

I haven't archived anything on this page. Miszabot does not implement an "archive now" command. But I see no reason in keeping stale discussions around for one or two years. Perhaps the section could be hatted to reduce the clutter on the page, and denoted "closed, please do not edit" to avoid escaping archiving. Miszabot is currently set for 30 days; perhaps that is too short. Jeh (talk) 07:43, 12 October 2015 (UTC)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

You haven't changed any essentials from what you've said before; you have merely heaped on more layers of confusing, self-contradictory verbiage. The wording in the article is still fine. "64-bit instruction set of x86 processor" is still potentially confusing to those who do not know the correct meaning of x86. Jeh (talk) 01:21, 11 October 2015 (UTC)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

And if pigs didn't have wings, they couldn't fly. See, they can't! QED. Jeh (talk) 03:34, 11 October 2015 (UTC)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

But x86-64, unlike ARM, is backwards-compatible with IA-32, just as IA-32 was backwards-compatible with 16-bit x86 or, as Intel called 16-bit x86 in the 80386 document I cited, " the 86/186/286 instruction set". So a processor that supported IA-32 and A64 would be different from a processor that supports IA-32 and x86-64 - in fact, a processor that supports x86-64 would, by definition, support IA-32, as x86-64 is a superset of IA-32 (just as a processor that supports IA-32 would, by definition, support 16-bit x86). (In fact, a processor that supported IA-32 and A64 would be somewhat like an ARMv8-A processor, given how different A32/T32 and A64 are. :-))

So there's a very important difference here between, for example, x86-64 and A64, and it's a difference that people reading about x86 and x86-64 need to understand. Guy Harris (talk) 03:48, 11 October 2015 (UTC)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

"52-bit limitation is the architectural limitation for IA-32 architecture processor" There's nothing about 52-bit physical addressing in Volume 3 of the Pentium Pro documentation, the Pentium Pro being the first IA-32 processor with PAE. It's x86-64 that allows 52-bit physical addresses in long and legacy modes; I won't believe that any IA-32 processor could handle 52-bit physical addressing unless I see a see a manual for such a processor ("such a processor" must not support x86-64 - if it supports x86-64, it's an x86-64 processor, not an IA-32 processor). Guy Harris (talk) 10:12, 11 October 2015 (UTC)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

"OK, 52-bit physical address is the limitation of what architecture?"

For Intel, a 64-bit PTE "with IA-32e paging", according to figure 4-11 "Formats of CR3 and Paging-Structure Entries with IA-32e Paging" in Volume 3 of the Intel 64 and IA-32 manual has room for up to 40 bits of "address of 4KB page frame", 30 bits of "address of 2MB page frame", and 22 bits of "address of 1GB page frame". Add to those the number of bits necessary for a byte offset within the page frame, i.e. 12 bits for 4KB, 22 bits for 2MB, and 30 bits for 1GB, and you get 52 bits in all three cases, so, for Intel 64, the architectural physical address limit is 52 bits, unless they really meant to say "reserved" rather than "ignored" for the higher bits. For what it's worth, those bits are all marked as "reserved" in figure 4-7 "Formats of CR3 and Paging-Structure Entries with PAE Paging", so that could be read as implying a larger maximum physical address in legacy mode than in long mode, but I really doubt that's what they had in mind. Perhaps "ignored" means "free for software to use, as the hardware will never ever look at them", which would mean that Intel 64 imposes a hard 52-bit limit that could only be lifted by a new mode, so as not to break operating systems that stuff additional information into those bits.

For AMD, a 64-bit PTE in "long mode", according to figures 5-21 "4-Kbyte PTE—Long Mode", 5-25 "2-Mbyte PDE—Long Mode", and 5-28 "1-Gbyte PDPE—Long Mode" of Volume 2 of the AMD64 documentation, the physical page base address has the same size as it does in the Intel 64 documentation, although the bits above the physical address are marked as "available" rather than "ignored" - I don't know whether that means that they are architecturally available for use by software, which would mean that AMD64 imposes a hard 52-bit limit that could only be lifted by a new mode, so as not to break operating systems that stuff additional information into those bits.

So it appears that the 52-bit physical address is a limitation of x86-64, in both its Intel 64 and AMD64 flavors, and that AMD64 does not change that.

Unfortunately, I can't find any copies of "IA-32 Intel Architecture Software Developer's Manual Volume 3: System Programming Guide" to see whether the 36-bit limitation of Pentium Pro continued all the way with IA-32 until Intel went with x86-64, so there might have been an increase in the maximum physical address size in IA-32 beyond 2³⁶ bytes prior to the introduction of x86-64. Guy Harris (talk) 17:44, 11 October 2015 (UTC)

FYI, Windows regards bits 52 through 62 of the PTE as available for use by the OS, and uses them as a "working set list index" - a way to quickly find, in the WSL, the entry that corresponds to the physical page whose PFN is in the PTE. And of course it treats Intel64 and AMD64 the same in this regard.

In the AMD doc, page 140: "Available to Software (AVL) Bit. These bits are not interpreted by the processor and are available for use by system software." Jeh (talk) 18:23, 11 October 2015 (UTC)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

"The physical address in this paging schema has been expanded from 32-bit to 64-bit" No. The page table entries and page descriptor entries were expanded from 32 bits to 64 bits in PAE. In the 64-bit page table entry for 4K byte pages, bits 0 through 8 are used as flags, bits 9 through 11 are marked as "Avail.", which I'm guessing means "reserved for software, the hardware will never use these", bits 12 through 35 are the physical address, and bits 36 through 63 are reserved (and should be set to 0). That gives 24 bits of physical address, which, combined with 12 bits of byte offset within the page, gives 36 bits of physical address.

"This architecture in architectural-limit might possible point to this PAE paging schema, rather than instruction set architecture." The term "instruction set architecture" is used both to refer just to instruction sets (that's how ARM uses it; A32, T32, and A64 are instruction sets, and various versions of the "ARM architecture" support one or more of those instruction sets, as well as other features such as a memory management unit in some versions) and to refer to other features of the architecture as well, such as the memory management unit. In the case of x86, the "instruction set architecture" also includes the MMU.

I don't have a copy of the last IA-32-only version of Intel's documentation, so I don't know whether it also had a 36-bit limit on physical addresses, i.e. whether it required that bits 36 through 62 must be zero, and bit 63 might be required to be zero or might be the "no execute"/"execute disable" bit.

As for AMD64 and Intel 64, AMD says in Volume 2 of the AMD64 manual that, in a 64-bit PTE, bits 52 through 62 of the PTE are "reserved, MBZ" (Must Be Zero) and that, for the Physical-Page Base Address, "This is an architectural limit. A given implementation may support fewer bits.", so they appear to be saying that 52 bits of physical address is an architectural limit, although, by marking the upper bits as "reserved, MBZ" rather than "available", they might leave open the possibility of going beyond 52 bits without requiring a mode bit - I read "reserved, MBZ" as meaning that an operating system should NOT put its own data into those bits, it should set them to zero, and, in the future, on a system with more than 4 PB of main memory, with a processor doesn't ignore those bits, it could set them to non-zero values to refer to the memory beyond 4 PB. In Volume 3 of the Intel 64/IA-32 manual, however, bits 52 through 58 of the PTE are "ignored" (not "reserved, MBZ"), and bits 59 through 62 are interpreted as "the protection key of the page" if CR4.PKE is 1 and are ignored otherwise. This indicates that it'd be harder for Intel 64 to go above 4 PB of main memory, as its spec appears to promise that some of those bits are "ignored" (so that an operating system could put its own data there, and not fail if those bits are used for the page physical address in the future) and that some of them can be interpreted as the protection key of the page.

"But AMD64 does not extend that architecture for physical addressing in legacy mode." Wrong. Figure 5-12, "PAE Paging Legacy-Mode" of Volume 2 of the AMD64 manual shows bits 12 through 52 - not bits 12 through 35 - being used for the "Physical-Page Base Address".

"Paging, PAE paging are both the processor-side features, they are like some an additional unit attached between processor and system memory" But that's not what it is - x86 processors, starting with the 286, have had the MMU on the CPU chip, unlike, for example, the 68k family, where the MMU wasn't on the CPU chip until the 68030. And both Intel and AMD document the operation of the MMU in the manual for the architecture, so it's not something separate for the architecture.

"You can also compare it with yesterday FPU located aside CPU processor, even though all of them were discussed in most instruction set architecture documents." Yes, and floating point is part of the instruction set architecture as well. Guy Harris (talk) 05:34, 12 October 2015 (UTC)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

The "reserved, MBZ" indication from the AMD doc is all in the "legacy mode" section 5.2. This is what would be used under a 32-bit OS. For a 64-bit OS we want section 5.3, "Long-Mode Page Translation". The PTE, etc., formats shown on page 133, 135, and 137 describe bits 52 through 62 as "available". The description of fields in section 5.4 says that that means "available to software". So, a 64-bit operating system can put its own data into those bits, just as is allowed for bits 9, 10, and 11. (I'm not disputing that writing nonzeroes to bits 52-62 would be disallowed in legacy mode. But that is irrelevant to a 64-bit OS.) As I mentioned previously, x64 Windows most definitely uses them (for a "working set list index" value). (See Windows Internals, Sixth Edition, part 2, page 266.)

So, yes, there is room to think that the architectural limit of 4 PB of RAM could be easily raised, without breaking existing OS code... but only for a legacy mode (32-bit) OS! For a long mode OS we are just going to be "stuck" at 4 PB without requiring OS changes. We will just all have to find ways to cope with this crippling restriction. (*grin*)

As for the "software protection key" feature described for Intel64, that appears to be quite new! It isn't in the September 2014 book, but is in the June 2015. Jeh (talk) 06:12, 12 October 2015 (UTC)

Processors are implementations of an architecture, so a "processor feature" may be specified by the architecture. Paging, as well as segmentation, are described in Volume 2 of the "AMD64 Architecture Programmer’s Manual and volume 3 of the Intel 64 and IA-32 Architectures Software Developer’s Manual. Those documents guarantee that all AMD64 processors will do paging in the fashion described in the first of those manuals and all Intel 64 and IA-32 processors will do paging in the fashion described in the second of those manuals; it's not as if each AMD64 processor or each Intel 64 or IA-32 processor gets to implement its own unique form of paging. The whole point of an architecture manual is to eliminate or, at least, minimize the amount of code that has to be changed or written new for a new processor; this includes not only user-mode code but operating system kernel code - the part of the virtual memory code that handles page tables doesn't have to be completely rewritten for each new x86 processor or System/3x0-or-z/Architecture processor, although it might need to change for new versions of some RISC processors where they chose not to put the MMU into the architecture (or even some older CISC processors like that, such as the earlier Motorola 68k processors). So, no, I don't accept any purported explanation of paging being a "processor feature" not connected with the architecture. Paging might not be visible from userland code, and even some kernel code, but there's code that has to manipulate the page tables, and either that code can be the same for all processors, if it's specified as part of the architecture as is the case in x86, or it might have to be different for different processors, if it's not specified.

And Jeh noticed that the description of the PTEs in long mode explicitly says that the bits between the NX bit and the page physical address are "available" for software use, so both AMD64 and Intel 64 will need a mode bit in order to access more than 4 PB of main memory; that limit is specified in architecture manuals, so it's part of the architecture. Guy Harris (talk) 07:04, 12 October 2015 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on X86-64. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive http://web.archive.org/web/20110609204027/http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/31116-Public-GH-BKDG_3.20_2-4-09.pdf to http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/31116-Public-GH-BKDG_3.20_2-4-09.pdf

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 03:55, 28 February 2016 (UTC)

I found where it moved to, and update the page. Guy Harris (talk) 04:35, 28 February 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 6 external links on X86-64. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added {{dead link}} tag to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmdac/html/data_mdacroadmap.asp
• Added archive https://web.archive.org/20070621084244/http://contracts.corporate.findlaw.com:80/agreements/amd/intel.license.2001.01.01.html to http://contracts.corporate.findlaw.com/agreements/amd/intel.license.2001.01.01.html
• Added archive http://web.archive.org/web/20100813052749/http://stanford-online.stanford.edu/courses/ee380/000927-ee380-100.asx to http://stanford-online.stanford.edu/courses/ee380/000927-ee380-100.asx
• Added archive http://web.archive.org/web/20100813100133/http://stanford-online.stanford.edu/courses/ee380/040107-ee380-100.asx to http://stanford-online.stanford.edu/courses/ee380/040107-ee380-100.asx
• Added archive https://web.archive.org/web/20040715225038/http://www.linux.org.uk/~ajh/gcc/gccsummit-2003-proceedings.pdf to http://www.linux.org.uk/~ajh/gcc/gccsummit-2003-proceedings.pdf
• Added archive http://web.archive.org/web/20110403005033/http://software.intel.com:80/en-us/articles/all-about-64-bits/ to http://software.intel.com/en-us/articles/all-about-64-bits/
• Added archive http://web.archive.org/web/20100123010204/http://software.intel.com:80/en-us/articles/seven-steps-of-migrating-a-program-to-a-64-bit-system/ to http://software.intel.com/en-us/articles/seven-steps-of-migrating-a-program-to-a-64-bit-system/

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 13:35, 21 July 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on X86-64. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20100910014057/http://www.x86-64.org:80/pipermail/announce/2001-June/000020.html to http://www.x86-64.org/pipermail/announce/2001-June/000020.html

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 23:16, 8 November 2016 (UTC)

Clarification needed

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,[1](p2)(p3)(p13)(p117)(p120) extending the virtual address space to 16 EB (264 bytes). This is compared to just 4 GB (232 bytes) for the x86.[15]

I don't understand this paragraph - does't AMD64 refer to x86? So what is being compared against in this sentence: This is compared to just 4 GB (232 bytes) for the x86? 169.0.179.29 (talk) 10:59, 12 December 2016 (UTC)

"x86" is, there, referring to 32-bit x86, also known as IA-32. x86 has 16-bit (8086/8088, 80186/80188, 80286), 32-bit (IA-32), and 64-bit (AMD64/Intel64/x86-64) versions. That part of the article sometimes qualifies references to x86 as "32-bit x86" and sometimes doesn't (at the time AMD64 came out, there wasn't an existing 64-bit x86). Guy Harris (talk) 19:08, 12 December 2016 (UTC)

Layman tag for this article?

Should we put a tag at the beginning of the article indicating that the article can or cannot be understood by a layman? --Polytope4d (talk) 18:05, 31 March 2017 (UTC)

x86-64 is 64-bit version of x86 Instruction Set?

To answer this very question, what is x86 exactly? An instruction set, or an architecture, or both of them? Instruction set architecture is instruction set architecture, instruction set is instruction set. They both are two things! For this very question, for years, I could not find any clue to prove that x86-64 is 64-bit version of x86 instruction set, no matter from Intel or AMD communities. If the manufacturers, inventors, vendors and so forth and so on could not prove it, how can someone else could make such irresponsible conclusion? Show my greatest objection to this statement! — Preceding unsigned comment added by 221.9.17.100 (talk) 07:11, 6 May 2017 (UTC)

"what is x86 exactly?" x86 is a term that is used to refer to, among other things, the 16-bit, 32-bit, and 64-bit versions of the instruction set architecture that started with the 8086 and continued to the current x86-64 processors. Intel hasn't used it in ages, if ever, for any purpose. AMD uses it to refer to the pre-64-bit version, as does Microsoft. Oracle, as per the link I cited, uses it when speaking of their 64-bit servers, and this article also uses "x86" to refer to the full range.

The 80286 added segmented virtual memory, and some new instructions, to that instruction set architecture; the 80386 added 32-bit support and paged virtual memory; various other processors added additional instructions (MMX, SSE, etc.); the Opteron added 64-bit support and some more instructions; processors subsequent to it added additional instructions.

So if x86-64 is an extension to the 32-bit version of x86, 32-bit x86 is an extension to the 16-bit version of x86; it's not a Shiny Brand New Instruction Set, it just continues the evolution of the existing instruction set, as anybody who actually reads and understands the instruction set descriptions can clearly see. Guy Harris (talk) 07:40, 6 May 2017 (UTC)

Well, thank you very much first! American English is derived from British English, but can people call it some version of British English, when more and more People in GB are trying to change their tone into American style? IA-32 is not the 32-bit version of x86 architecture. x86 is used by the industries to refer the processors and their architecture same or similar with IA-32. Because the legacy part of x86-64 processors are the same or similar as the IA-32 architecture, so the x86-64 processors are also referred as x86 processors, but in essence, they are 64-bit x86-64 processors.

Extension could not always be counted as a version, for many reasons. But the most important reason is that this 64-bit extension is not a completely 64-bit extension of IA-32 (or x86), leaving so many aspects of it uncertain to the future. Comparing to a true 64-bit version of IA-32, it is just like a once 64-bit extension of x86, or a 64-bit variety of x86 architecture exactly. In Intel documents, IA-32 and Intel 64 architectures are differentiated intentionally, or in other words, Intel never treat the architecture of Intel 64 as some version of IA-32, or x86, but merely treat it as an 64-bit architecture associated with Intel IA-32 architecture. And many early documents also called this AMD developed 64-bit ISA as the 64-bit instructions sets of Intel IA-32 processors. That is not a mistake by Intel, because they were and are just the IA-32 processors, but just enhanced by this 64-bit extension developed by AMD, based on IA-32. 221.9.17.100 (talk) 08:17, 6 May 2017 (UTC)

"But the most important reason is that this 64-bit extension is not a completely 64-bit extension of IA-32 (or x86), leaving so many aspects of it uncertain to the future." Really? Name one such aspect.

"Comparing to a true 64-bit version of IA-32" What "true 64-bit [versions] of IA-32" are there to compare with?

Look. x86-64 is a 64-bit architecture, with 64-bit registers, 64-bit pointers (with some of the address range currently not mappable), and 64-bit arithmetic. It adds to x86 the REX prefix, which is only available in long mode because it uses the same encoding as the existing 1-byte opcodes for INC and DEC (the 2-byte opcodes are still supported in long mode). It does not provide segmentation in long mode, i.e. no 84-bit segmented addresses with a 64-bit segment offset, so some instructions are disabled in long mode. For some reason, the "ASCII Adjust" instructions and the BOUND instruction are disabled in long mode. So it basically uses the same instruction set and same instruction encoding as are in the 32-bit instruction set, with segmentation removed (some stub use of FS and GS are provided, probably for use with per-thread data and the like), with a few instructions removed, and with one of two encodings for incrementing and decrementing the A register removed and used for an additional prefix. So what makes x86-64 not "a true 64-bit version of IA-32"? How would you have made "a true 64-bit version of IA-32"?

Similarly, the 32-bit version of x86 (which needs a better name than "IA-32", as 1) it wasn't just implemented by Intel, and AMD added instructions to it just as Intel did and 2) Intel can't seem to make up their minds as to whether "IA-32" includes the 16-bit instruction set or not - in the same document in two nearby paragraphs they speak of it in ways that suggest that it does and suggest that it doesn't) added to x86 address and operand size prefixes (for which, fortunately, there was opcode space, so they didn't have to steal some instruction codings). So it basically uses the same instruction set and instruction encodings as are in the 16-bit instruction set, with some additional prefixes. Guy Harris (talk) 09:10, 6 May 2017 (UTC)

From the AMD Architecture manual: "The AMD64 architecture is a simple yet powerful 64-bit, backward-compatible extension of the industry-standard (legacy) x86 architecture."

And yes, an "extension" is a modification of the previous, and therefore is a version of the previous. Or else this is a strange new meaning of the word "version" that everyone except the IP was previously unaware of.

btw, neither Intel nor AMD coined the term "x86", so it matters not what an anonymous self-proclaimed "Intel engineer" said in a forum post. It's an industry-wide term, and currently includes 16-, 32-, and 64-bit architectures.

This little dispute originates solely in the IP's peculiar interpretation of English. Jeh (talk) 17:56, 6 May 2017 (UTC)

Guy, I've read your words. Sorry, definitely you are wrong! 119.53.109.114 (talk) 22:48, 6 May 2017 (UTC)

We have solid references on our side. And it would be trivial to find many more. You're going to need a lot more than your declaration of "you definitely are wrong!" to counter them. Until you do, your edits will continue to be reverted, as they are unsupported by reliable sources while the claims made in the article are so supported. Face it - Wikipedia is simply not going to be edited to suit your peculiar interpretation of either the "horse's mouth" documents in the field, or your peculiar interpretation of English - not unless you have RSs for them.

Now if you want to do it the right way, you could go find some RSs that claim that x86-64 is not a version of x86. Then we could document that as a difference of opinion among experts. If there is a preponderance of sources that state that, then we would even have to say that that was the prevailing opinion. Wouldn't that be a great victory for you?

But if you just want to expound on your view of these matters, but without citing Wikipedia-grade reliable sources to back it up - which seems to be what you're trying to do here - I suggest you start a blog. Jeh (talk) 02:55, 7 May 2017 (UTC)

x86-64 is a 64-bit version of x86? Give some proofs!

Section started by blocked user
The following discussion has been closed by jeh. Please do not modify it.
x86-64 is a 64-bit version of x86? Give some proofs! @Guy Harris:, if you find something wrong with the description like x86-64 (also known as x64, x86_64, AMD64 and Intel 64[note 1]) is the 64-bit architectural extension of the industry-standard x86 architecture, this 64-bit architecture also includes x86 within its legacy mode, would you please consult with both AMD and Intel companies, rather than fabricate the term or description? — Preceding unsigned comment added by 221.9.17.174 (talk) 22:58, 15 May 2017‎ (UTC) Well, one, that description is a near-copy from the AMD architecture book; we can't use it per WP:COPYVIO. (Changing a few words and a few word orderings is not sufficient.) Two, neither AMD nor Intel defined or own the term x86. Their opinion is not definitive. It is an industry-wide term, used in a very large number of trade journals, books, and the like. And most of those uses show that it means the architectures that first saw the light of day with the 8086, now including x86-64 (= x64). Numerous references for this have already been provided. You can continue to ignore them if you wish but that doesn't make them go away. Three, your claims simply fly in the face of standard English usage (which has always been a problem with much of your writing - even when you've had a valid point it's been very difficult to figure out what you're saying). It is remarkable, by the way, that you insist that x86-64 is an extension of x86, but you have objected strenuously to the claim that x64 in long mode uses ~"an extended form of PAE" (or "enhanced"). Jeh (talk) 07:23, 16 May 2017 (UTC) And at least one of the uses of "x86" that includes 64-bit processors came from Intel itself (from Intel, not the "lady from Intel"). Guy Harris (talk) 07:35, 16 May 2017 (UTC) Oh, and as for AMD documents, AMD64 Architecture Programmer’s Manual, Volume 1: Application Programming, chapter 1 "Overview of the AMD64 Architecture", section 1.1 "Introduction", second paragraph, says: The need for a 64-bit x86 architecture is driven by applications that address large amounts of virtual and physical memory, such as high-performance servers, database management systems, and CAD tools. Gee, what might that "64-bit x86 architecture" be? AMD64, perhaps? Maybe AMD does think there is such a thing as a "64-bit x86 architecture". Guy Harris (talk) 08:49, 16 May 2017 (UTC) No, this is not a near-copy from AMD documents. "we", what do you refer to? Only you? You provide nothing at all, sorry! — Preceding unsigned comment added by 119.53.115.198 (talk) 08:32, 16 May 2017 (UTC) "Gee, what might that "64-bit x86 architecture" be? AMD64, perhaps? Maybe AMD does think there is such a thing as a '64-bit x86 architecture'". Yeah, I see you've already answered one question that you always stick to is only a presumption, rather than the fact. So this 64-bit version of x86 is fabricated. Like what it said, the need for a 64-bit x86 architecture eventually brought out the 64-bit architectural extension of x86 architecture. I have completely no ideas why such a programming expert who worked in that field more than 40 years stick to the thing which is not that consolidate as it were. In other words, 64-bit x86 architecture does not mean anything around 64-bit version of x86 architecture. They both are different things, how can someone treat them the same? Even if there is an architecture, 64-bit x86 architecture, and there is no evidence(s) to say this x86 architecture has been expanded onto 64-bit, and its new version is that 64-bit x86 architecture. No, completely no! x86 is an architecture, publicly recognised by the IT industry. The x86-64 is just the 64-bit extension of x86. Here I repeat again, the relationship of x86 and x86-64 is not possession, but extension, of course, the latter extends the former. 64-bit extension of sth. does not mean 64-bitlised sth., it can 64-bitlise sth., but it can also divert it far away. AMD differentiate x86 and AMD64 obviously in their official documents, Intel also do the similar thing. You can call the x86 is a class, but you can never call it architectures! Because x86 is an architecture since the very beginning to the very ending! — Preceding unsigned comment added by 119.53.118.103 (talk) 09:07, 16 May 2017‎ (UTC) " 64-bit x86 architecture does not mean anything around 64-bit version of x86 architecture. " Of course it does. That you do not agree with this shows that you are not competent to contribute to English language Wikipedia. Your only arguments are based on your interpretations of words, interpretations that no one else ever seen on these pages, except of course for your numerous sockpuppets, shares. Jeh (talk) 09:34, 16 May 2017 (UTC) Who the earth are you? I am very sorry I did not spent any penny on your training, so I would not buy any word you said anywhere. But your words are quite funny as usual. For one thing, are you English speaker (native or not)? Sorry, I could never see any piece of that! I have bunch of friends from Ireland, UK and France, they did not trust you are one of them through your expression in English. Maybe you are from some other land? China? Or some elsewhere! Words in any language are used to express rather than fabricate, I wish you could understand! Sorry, I am very tired to mention that stupid name and stupid company. — Preceding unsigned comment added by 119.53.118.103 (talk) 10:44, 16 May 2017 (UTC)

Let us vote!

Wikipedia is not a democracy
The following discussion has been closed by Murph9000. Please do not modify it.
Hello readers from all over the world, no matter who you are, what you are; if you found this title please vote! Options: I. The x86-64 is the 64-bit version of x86 instruction set. II. The x86-64 is the 64-bit architectural extension of industry-standard x86 architecture, this 64-bit architecture also reserves the x86 as legacy. Requirement: Each IP or user id could only vote once! If you like, you could give your reasons and/or suggestions on that! Thank you in advanced! Please write your vote below, and sign your post. Votes: 1.I vote option II. 221.9.23.59 (talk) 13:41, 16 May 2017 (UTC) 0.Sockpuppets don't get to vote. Jeh (talk) 13:53, 16 May 2017 (UTC) I do appreciate your reply, but please go to the correct places rather than here to deal with your own business. You have your own choice to vote, or give up. If you continue involving unrelated things here, you are admitting that you give up your vote. 221.9.23.59 (talk) 14:00, 16 May 2017 (UTC) Wikipedia is not a democracy. There are no votes here. Your premise of "voting" is invalid, so I'm not giving anything up. Consensus is against you. You could take a "straw poll" just to see where everyone stands, but the results are not binding. You don't get to reformat my replies, either. Jeh (talk) 14:12, 16 May 2017 (UTC)

Protected edit request on 16 May 2017

In the video game consoles section, the paragraph states:

Both PlayStation 4 and Xbox One and their successors incorporate AMD x86-64 processors, based on Jaguar microarchitecture[78][79]. Firmware and games are written in the x86-64 codes, no legacy x86 codes are involved with them.

I would like it changed to:

Both the PlayStation 4 and Xbox One incorporate x86-64 processors from AMD's Jaguar microarchitecture.[78][79] Firmware and games are written specifically for the architecture, without the need for code written for the legacy x86 component.

Because it is not very well written and I would like it corrected and clarified. Here's the markup.

Both the [[PlayStation 4]] and [[Xbox One]] incorporate x86-64 processors from AMD's [[Jaguar (microarchitecture)|Jaguar]] [[microarchitecture]].<ref name=XboxOneMay2013Anandtechcomparison>{{cite news |title= The Xbox One: Hardware Analysis & Comparison to PlayStation 4 |author= Anand Lal Shimpi |publisher= Anandtech |url= http://www.anandtech.com/show/6972/xbox-one-hardware-compared-to-playstation-4/2 |date= 2013-05-21 |accessdate= 2013-05-22}}</ref><ref name=XboxOneMay2013SpecGameinformer>{{cite web |url= http://www.gameinformer.com/b/news/archive/2013/05/21/the-tech-spec-test-xbox-one-vs-playstation-4.aspx |title= The Tech Spec Test: Xbox One Vs. PlayStation 4 |publisher= Game Informer |date= 2013-05-21 |accessdate= 2013-05-22}}</ref> Firmware and games are written specifically for the architecture, without the need for code written for the legacy x86 component.

Thank you. FosterHaven (talk) 16:08, 16 May 2017 (UTC)

@FosterHaven: Not done: The page's protection level has changed since this request was placed. You should now be able to edit the page yourself. If you still seem to be unable to, please reopen the request with further details. Murph9000 (talk) 08:43, 20 May 2017 (UTC)

@Murph9000: Thank you! FosterHaven (talk) 15:21, 20 May 2017 (UTC)

"without the need for code written for the legacy x86 component"

Your request to edit it is appreciated, but you change the meaning of that sentence. Because there arise another question, are the codes written in x86 able to work on those game consoles? Many years passed after they both introduced, Microsoft provides an virtual zone for Xbox One to run their customised Windows 10 on it, but there is no voice about the backward capabilities with x86 software. As to the PS4, there is nobody hacking it and enable it to work as a traditional PC. If you read my words on the talk page of x86, you would find the differences between x64 and x86-64 processor. One could make sure that both game consoles use x86-64 processors, but unsure that they are x64 processors or not. If they are not x64 processors, in other words, they may be incapable to run x86 application if without support from software. So this necessary would turn to possibility.119.53.119.155 (talk) 22:31, 16 May 2017 (UTC)

Both the PlayStation 4 and Xbox One incorporate x86-64 processors from AMD's Jaguar microarchitecture.[78][79] Firmware and games are written specifically for the architecture, without the need for code written for the legacy x86 component.

There are some problems after you changed,

1. You censored the "successors", you might possibly treat those successors are the following versions of PS4 or Xbox One, or treat them as the same things.

2. Processors from microarchitecture, yeah, processors are the physical realisation of specific microarchitecture, but such expression is quite rare to find.

3. What is the legacy x86 component? Your expression might embrace the content of your own opinion or guess, such as "the need for". Why the designers and developers of game consoles put too much effort to the things they do not really care about?

In my own opinion, your version is a little bit worse than the former. But I do appreciate your request. 119.53.110.4 (talk) 07:30, 17 May 2017 (UTC)

---

I'm very willing to believe you don't actually appreciate my contribution. I just read up the sections in the x86 talk page you mentioned that actually wasted Guy Harris' time. Let me counter-argue in full support of his word salad claim:

are the codes written in x86 able to work on those game consoles?

If by "codes" you mean the raw instructions, then I would like to point out that if it doesn't, then it's not an x86 processor. x86-64 is an extension of x86; it extends the capabilities of the x86 architecture to support 64-bit instructions. And if you couldn't tell what that means, x86-64 supports x86 instructions. At least, that's what the article should explain. If it didn't do that, then by all means, create an account and edit it so that it does.

And I can tell you're inexperienced because absolutely nobody refers to programs as "codes".

As to the PS4, there is nobody hacking it and enable it to work as a traditional PC.

I raise this blog post by fail0verflow detailing how they ported Linux to the PS4. And don't bring up "but it's Linux, not Windows," that just means you can do way more with the system than Microsoft allows with Windows. It's always been like that for Linux.

There are some problems after you changed, [...] [and] your version is a little bit worse than the former. But I do appreciate your request.

Subtle. But here's why those problems don't actually apply:

You censored the "successors", you might possibly treat those successors are the following versions of PS4 or Xbox One

You might. But that's not what censorship is. I've removed it because we don't know if the successor consoles will have the same processors, and it's certainly not Wikipedia's job to speculate on that. A reliable source would have to confirm leaked or revealed information, and that obviously hasn't happened in the years that the consoles have been out. (As per the fact that "a schedule of future events may be appropriate if it can be verified.")

yeah, processors are the physical realisation of specific microarchitecture, but such expression is quite rare to find.

It's actually not rare, so what's the "problem" you speak of? Is my expression not good enough for Wikipedia?

What is the legacy x86 component? Your expression might embrace the content of your own opinion or guess, such as "the need for".

It's a copyedit. My expression embraces Wikipedia's perspective, which I didn't know was actually yours before I arrived. If a copyedit contains bias somehow, then the editor is not doing a very good job.

Why the designers and developers of game consoles put too much effort to the things they do not really care about?

That's not for us to explain, certainly not on this article. And that's probably why that second sentence isn't even needed.

So with your points countered, I would like explain what it is you're trying to do, because I know it very well; you are setting a trap, and so far it's worked. You show persistence, and a pure lack of involvement in the project's efforts. The first thing you tell us is that you try to find the claims we make, and apparently you can't? And so we're wrong as a result? And after failing to take in the opposing side, you insist that your conclusion is the correct one, even when Guy Harris stated the proof you brought up had went against your claims. So when he's proved all he's needed to, you go out of your way to get the last word as if it actually matters. And then, while I wander onto the page and see what I believe is an error, and suggest it accordingly because it's restricted, you dissect my copyedit for "changing the meaning of the sentence" which is basically that it goes against your perspective.

So let me clarify. x86 is a set of architectures, x86-64 is the 64-bit architecture that adds more capabilities and is backwards compatible with x86. You cannot argue otherwise when scientific journals are using the jargon without your involvement. I sincerely apologize that you're not important to this article, but we rely on them for our facts, not you. Don't go around this place acting like you own it, because you don't even have an account, and I assume if you made one, you would get your editing privileges revoked immediately.

I had been off to do other things for two days whilst not even being aware of this whole discussion taking place. I did not notice what happened at all but now I'm very, very glad I did, thanks to Murph notifying me above. FosterHaven (talk) 15:21, 20 May 2017 (UTC)

Ignore the IP. The IP's edit warring and attempts to edit against consensus is the reason the page has been protected. If you read the IP's words on talk page of x86, and responses thereto, you will find that her/his assumption that x86-64 and x64 are, or could in any way be considered, two different things is completely unsupported. Jeh (talk) 02:37, 17 May 2017 (UTC)

@Jeh: I figured that was the case after I skimmed it. I'll be removing the second sentence in the section, since I feel like it's a fact that shouldn't need to be stated already. FosterHaven (talk) 15:21, 20 May 2017 (UTC)

I've you read your words, and that is enough! 221.9.20.168 (talk) 05:09, 21 May 2017 (UTC)

I'm just being honest, even if a bit pushy. I know you want to help this article (and you should know that everyone here wants to, otherwise what would be the point), but not everyone is going to be on your side if you argue against the editors about how the article and the writers are wrong. Ultimately, Wikipedia being a collaborative effort means that even though we do value input, it's not a necessity to insert your perspective. I'm not saying we don't need your help at all, but you're positioning yourself in a bad spot so if you want to help, you'd have to follow the consensus. There's really not much more for me to say. FosterHaven (talk) 13:08, 21 May 2017 (UTC)

Thank you for your reply. In 2008, you were 9, but I was 24. I read articles on Wikipedia.org since late 2004, I got in touch with x86-64 processor in that same year too. I experienced Windows XP on IA-32, Itanium and x64 platforms, I experienced the Xbox in your words too when in high school. So ..., ok, you are welcome. — Preceding unsigned comment added by 221.9.19.34 (talk) 14:53, 21 May 2017 (UTC)

In 2008, I was 44, but you were only 24. It got "in touch" with x86 in 1986. You were 2. Looks like you are using a mix of the Appeal to accomplishment and Appeal to tradition. Fallacies aside, I've been reading this discussion with some interest. It appears to me to be a mix of trying to find and communicate the history of events correctly mixed with a misunderstanding that phrases like "x86-64" and "architecture" don't always maintain an exact meaning over time.War (talk) 18:59, 22 May 2017 (UTC)

x86 is a bunch of architectures, and x86-64 is only the 64-bit version instruction set?

From wiki article x86

"x86 is a family of backward-compatible instruction set architectures based on the Intel 8086 CPU and its Intel 8088 variant."

From wiki article x86-64

"x86-64 (also known as x64, x86_64, AMD64 and Intel 64 is the 64-bit version of the x86 instruction set."

Those two wiki articles say that the x86 architecture includes all the architecture(s) since Intel 8086 through Core i7 and AMD Ryzen; and x86-64 is only an instruction set of the former. I do not want to be accused as the human embodiment of the Dunning-Kruger effect by some a computer genius from Wikipedia.org, who experienced programming more than 40 years! Maybe writers and editors from AMD and Intel are fools because they deny them, by differentiating x86 and AMD64 or IA-32 and Intel 64. Most Linux distributions differentiate them both as x86 and x86-64 too, the very famous free productivity software, Libre Office differentiate them both in that way too. Maybe all of them are completely wrong, because they are not computer genius. Maybe Bill Gates is neither a computer genius, because his programming experiences began also more than 40 years ago, but today Microsoft also differentiate them both as x86 and x64.

A programmer with more than 40 years programming experiences would give the definitions like above about x86 and x86-64, I just realise the definition of computer genius maybe also need to be redefined! A person programmed for more than 40 years something like below,

"Repeating your assertions over and over again is not going to convince me. If you're also a software developer who's worked at that level, you can probably come up with arguments based on more than just arguments about the meaning of words; if you're just a fanboy who's read a bunch of articles and thinks that makes him an expert who can lecture people with more experience in the field, you're simply wasting your time and convincing us that you're a fool."

I understand I have to accept this person's words, "you're simply wasting your time"! For any penny, I have to say this guy is a computer genius! — Preceding unsigned comment added by 119.53.113.164 (talk • contribs) 08:00, 18 May 2017 UTC (UTC)

That is WAY TOO MUCH editorializing. If you have a specific section or sentence you think should change. Quote it and then propose what it can be changed to. We can discuss it. I won't discuss who is or isn't a genius or how many years experience someone has...neither is relevant.War (talk) 15:24, 25 May 2017 (UTC)

"AMD64 might have been AMD's response to IA-64", is it real?

We need sources! — Preceding unsigned comment added by 221.9.19.34 (talk) 10:23, 21 May 2017 (UTC)

1) "might have been" and 2) it's not a claim in an article, it's part of an edit comment. It's a possibility - I might have seen it suggested in an issue of Microprocessor Report, given that Intel and HP had a lot of patents on IA-64 and were not offering to license them to anybody, including AMD, AMD would have to do something if 64-bit processors became important. What they did was to come up with a 64-bit version of x86; whether that was the motivation for developing x86-64 is another matter. If I had a source, I'd put it in an article; as I don't, I'll mention it in discussions as a possibility, but not claim it to be a fact. Guy Harris (talk) 18:19, 21 May 2017 (UTC)

They are the words of many people, but that might not be the real story. Like SPARC or UltraSPARC, IA-64 was designed as an open architecture, in other words, the developers wished it could be implemented by lots of semi companies rather than only Intel. But for the complicated nature of EPIC IA-64 architecture and its unforeseen future, few semi-companies would be content to get that try. HP saw Intel had the largest number of consumers from the all over the world with their x86 based products. With the help of Intel, HP believed that rooting such processors onto the everyone's desktop would accelerate this architecture evolved to be mature and popular. With the efforts of Intel, this VLIW-based EPIC architecture embraced the farther relationship of x86 or IA-32, in those days when RISC processor played as an important role in server and professional market. Windows powered by Itanium would put a heavy beat towards Mac OS X on PowerPC. But, after all, x86 would never evolve into EPIC, and what Intel possessed all the time is the x86 rather than IA-64. But the future of x86 architecture might leave Intel an unclear future, with the disguise of Itanium, they swift from the focus on the architecture(s) onto the implementations, when x86 or IA-32 has already been mature. The earliest information on AMD64 from Microsoft is on the installation information of Windows XP in 2001. Maybe during all those days, no matter Intel or Microsoft consider a common question, why another x86 architecture? But for what reason why let that architecture gone if some a force is still working on? And the most important thing is that there were already so many out-of-box applications and developers who are familiar on such architecture. So they would be pleased with another x86 rather than like a fish flying on the sky, if transiting from x86 to EPIC IA-64.

Comparing with x86 or IA-32 architecture, when so many others are dead nowadays, but x86 is still strong even though its nature is 32-bit and x86-64 dominated the professional and server market. The reason is that the unique architectural characteristics of x86 make it easily be expanded and/or extended, and the backward supports for codes written on previous generations of processors could be kept retained. AMD model such things onto the x86-64 architecture, without even breaking the x86 architecture at any penny, because the native x86-64 architecture eventually evolved lacks almost everything around that.

When Intel released Itanium processor, there were no fears coming from AMD. Because that processor is only strong for its presumed architectural advantages but lacks the support base from everything what x86 processors already had, it did not even have a native OS to boot up. Since then to now, yup, there is not an O/S exclusively designed for Itanium, but only ported to it. When Microsoft released Windows XP 64-bit Edition (Version 2002) they did not even put it at the pace of Windows XP Professional for x86, without modern GUI, and without even needing an activation. But like AMD K6 processors, AMD put the things on Windows a second time to their processors, this time not the Windows Logo, but the 9x mirrored "xp" onto the name of their processors, Athlon xp. So AMD64 was not like AMD's response to IA-64, not then, not now!

"Like SPARC or UltraSPARC, IA-64 was designed as an open architecture, in other words, the developers wished it could be implemented by lots of semi companies rather than only Intel." Prove it.

"Windows powered by Itanium would put a heavy beat towards Mac OS X on PowerPC." Windows already had 90+% of the personal computer market, and it's not as if you needed more than x86 to beat PowerPC.

"but x86 is still strong even though its nature is 32-bit and x86-64 dominated the professional and server market." x86 started out as a 16-bit architecture, added 32-bit capabilities with the 80386, and added 64-bit capabilities with Opteron. There's nothing "naturally" 32-bit about it.

"The reason is that the unique architectural characteristics of x86 make it easily be expanded and/or extended, and the backward supports for codes written on previous generations of processors could be kept retained." The "unique architectural characteristics of x86" that made it dominant are the IBM Personal Computer, MS-DOS, and Windows, so processors implementing it were made in very high volume, and Intel could throw research and transistors at the problem of making it run fast. About the only thing about the x86 instruction set that could be viewed as making it more expandable than other instruction sets is the variable-length instruction encoding, but it's certainly not the only ISA that 1) went from 32 bits to 64 bits or 2) picked up a bunch of SIMD/vector extensions.

"When Intel released Itanium processor, there were no fears coming from AMD. Because that processor is only strong for its presumed architectural advantages but lacks the support base from everything what x86 processors already had, it did not even have a native OS to boot up" One does not only fear immediate threats - if the future were to go 64-bit, and AMD had no 64-bit processors, they'd be in trouble. They were an x86 vendor, so they'd either have to 1) find some vendor willing to license their 64-bit ISA, 2) invent a brand new ISA, or 3) invent 64-bit x86.

"Since then to now, yup, there is not an O/S exclusively designed for Itanium, but only ported to it." So what? Most of the OSes for the various RISC processors were ported to, or adapted for, those processors. Having a Shiny New OS for your Shiny New ISA isn't a requirement for its success.

I've ordered a copy of the Microprocessor Report article on AMD64. We'll see what it says. I may also order articles on IA-64 to see what they say about how "open" it was intended to be. Guy Harris (talk) 02:15, 22 May 2017 (UTC)

I think it will be hard to find a source that expresses AMD's "intent" vis-à-vis the Itanium. At the time there were many applications with memory issues and the x86 "extended memory" model just wasn't cutting it...especially with servers becomes more prominent. I bet you are more likely to find this as the driving force behind the AMD64 rather than a response to Itanium. War (talk) 19:16, 22 May 2017 (UTC)

The Microprocessor Report article in question, AMD Drops 64-Bit Hammer on x86 (it's behind a USD 95 paywall), didn't say anything about that (although it sure used "x86" a lot to refer to the instruction set family, from 16 bits to 64 bits, emphasis on "to 64 bits"). The question is whether AMD, at any point, realized that they wouldn't be able to track Intel into the 64-bit space, due to patents etc. (the MPR article does note that neither Intel nor AMD signed on any other processor for their architecture, the claims by Aaron Janagewen that "IA-64 was designed as an open architecture, in other words, the developers wished it could be implemented by lots of semi companies rather than only Intel" notwithstanding), and that this meant that AMD wasn't going to be able to continue forever as a 32-bit x86 vendor, and wouldn't be able to become an IA-64 vendor, if 64-bit computing became significant, and whether that contributed to their decision to go with x86-64. If Intel had gone with 64-bit x86 from the beginning, and if AMD's licensing of Intel patents would have covered that 64-bit x86, they might not have invented their own 64-bit x86.

However, perhaps they could have become, for example, a PowerPC vendor rather than becoming the first x86-64 vendor, so it's not as if not being able to implement IA-64 would necessarily have closed off all opportunities to go 64-bit other than "roll your own instruction set", although, at the time, IA-64 may have been viewed as a much bigger threat to other 64-bit architectures than it turned out to be, so they might have figured that the future would ultimately belong to IA-64 unless they could figure out a way to have a 64-bit ISA that would have a marketplace advantage over the other 64-bit processors - and "hey, it can run 32-bit x86 code, including OSes for 32-bit x86, at full speed, and it just adds things to x86 that an existing x86 compiler or operating system doesn't need a lot of work to deal with" seems to have been what they needed. Guy Harris (talk) 21:02, 22 May 2017 (UTC)

Intel announced the processor based on HP IA-64, Itanium, in year 1999; released the very first Intel Itanium processor in 2001, the very first Pentium 4 with EM64T enabled in year 2004, transmit the entire product line to Intel 64 in 2006. 2006 - 2001 = 5 years, or 2006 - 1999 = 7 years. Is it too long for the five years, transitioned from IA-32 to IA-64? Maybe in the former British Hong Kong, if you could stay there for more than 7 years, you would become a British Hong Kong citizen naturally. Intel 80386 was released in 1985, but when in 1994, most applications were most written in 16-bit codes, 1994 - 1985 = 9 years! I believe Intel had very few real expectations transition from IA-32 to IA-64, but only because actual AMD64 processor was not on earth during that time. Only one year later, Intel cannot wait to releasing their implementations of x86-64 architecture. And only two years later, they refreshed their entire product line with Intel 64 processors. Within so few years, Itanium was kept out, and become another solo ISA among others. So AMD64 was only advertised to be the AMD's response to IA-64, but it was not since the very beginning! 119.53.114.43 (talk) 02:02, 26 May 2017 (UTC)

I don't see how any of this discussion is going to lead to improvements in the article, which is what talk pages are for. We have no way to reliably source AMD's intentions or strategies of the late 90s. Jeh (talk) 07:27, 26 May 2017 (UTC)

Take an extent look of x86 or IA-32,

In the history of IBM PC and its compatible machines, the dominated Operating Systems are from Microsoft, such as MS-DOS, IBM PCDOS, Microsoft OS/2, IBM OS/2 Wrap, Windows 3.x, Windows 9x, Windows NT and Windows 2000/XP. Later IBM and Legend merge into Lenovo, the new IBM rather than the new Legend. IBM dropped their market on personal computing, and the new IBM, Lenovo lose all its dominated position in personal computing market. And that period was gone! IBM PC Compatible is gone too! But its platform rooted into today's personal computers.

What is x86 architecture? From another aspect of it, not constrained by the aspect from its inner world, another definition could be drawn,

The architecture (ISA) of IBM PC and all its compatibles is x86.

or

The x86 is the architecture of IBM PC and all its compatibles.

The dominated or major operating system for IBM PC are DOS and Windows! Such as 16-bit Windows, Windows 1.x/2.x/3.x; 16-bit/32-bit mixed Windows, such as Windows 3.1 Workgroup, Windows 95/95 OSR2/98/98SE/ME; 32-bit Windows, Windows NT/2000/XP. The architecture those operating system are build on is just the x86 architecture. And those Windows 9x operating systems are the good examples to say that this x86 architecture is an architecture rather than many. Because Windows 9x span over almost the entire modes of IA-32 processors in their running time. Omitting any one, these OSes would fail to work. From the aspect of a computing system rather than the level on the architecture of processor itself, the x86 is an architecture, rather than many. Of course, system based on 16-bit processors have no chances to work on Windows 9x, that is another reason to say the 16-bit architecture introduced by those 16-bit processors has been eventually evolved the IA-32 or x86 architecture. In other words, the x86 architecture is not separable. Another important role of Windows 9x is that they are the native OS for those IBM PC Compatibles and x86 processors. But Windows NT is not, they are not designed exclusively for x86 processors, in fact they are developed on an Intel RISC processors. The support for then mainstream RISC processors was their initial design purpose. On the port of x86, this OS just utilise the pure 32-bit mode, rather than saying that that 32-bit environment is the IA-32, or 32-bit version of x86. And what IA-32 refers to, in Intel official documents, has already stats the entire architecture of 32-bit processors, or x86, exactly.

Different from that Windows 95 is the native operating system for x86 architecture, Windows NT is a portable operating system. In order to make an OS to be portable, the designers must be in consideration of the differences among different architectures. They would design it carefully and avoid to get in touch with the unique features of each supported architecture, obviously, codes on those things are hard to be portable. In order to achieve this goal, the OS itself must be stand above a little bit higher than the native one. Like moving a building from a place to another, the most easiest way is put the live onto the bottom and contact part. Because moving that part, the remains above on it would follow its movement, without worrying it to be crushed. Windows NT, like so many other portable OS, such as Linux, BSD and VMS, it is built above on one portable abstract layer rather than get in touch with the hardware directly. For the port of x86, they just utilise the partial features found on the 32-bit architecture introduced by 80386, and denote such architecture as "i386" on its installation media. Of course, Windows NT is not designed exclusively and natively for x86 architecture. Even though the needs for backward support for the legacy 16-bit applications were important, they realise such features like in other ports, in the form of software emulation, rather than trap processors back to 16-bit real mode (like Windows 9x), or utilise the Virtual x86 mode. Like Windows NT, Linux is also a product of 80386 age. Even though Linux is not UNIX, but its ideas are brought from UNIX, so the process to make it realise on the 80386 processor is also a process of porting rather than design for x86 processor natively.

Evaluating the modern operating system and applications, AMD designed a 64-bit architecture, which is extended from x86 architecture, catering for those who are eager to port their current OS, rather than re-design from the ground, with enough support for the backward supports, and this 64-bit architecture is named as AMD64 or x86-64. Comparing with that Windows 9x is designed natively for x86 architecture, and Windows NT is actively ported to x86 architecture; this x86-64 architecture is designed intentionally for those modern OSes. Comparing to saying that Windows 9x is the native OS of x86; x86-64 is the native architecture for Windows, Linux, FreeBSD and so many other modern OSes. From the viewpoint of this, x86-64 is an architecture, rather than merely an instruction set. For its independence from legacy x86 architecture, it is an standalone architecture, rather than an 64-bit extension to the IA-32, like SSE, MMX and so forth.

Apple once gave an illusion that it were an 64-bit extension to the IA-32, like SSE, MMX and so forth since Mac OS X 10.4.6 though Mac OS X 10.7. But that is only an illusion, this special 32-bit kernel completely run within IA-32e mode rather than span the entire modes of Intel 64 processors. This link between IA-32 and Intel 64 is a fake. This once again says that the relationship between x86 and x86-64 is not the latter is part of the former, but just in the opposite, x8-64 succeeds the history of x86. Legacy in software development implies that those software would not be modified or updated. On x86-64 architecture, the shadows of x86 present itself in the legacy form no matter in Legacy mode or Compatibility Mode. Or in other words, the fundamental architecture of x86 has not been changed. In the words of AMD, it is called "backward compatible". This also stats that x86-64 is not the 64-bit version of x86, but for their similar natures, it is the 64-bit extension of x86 architecture. Or in other words, the x86-64 is designed mostly based on extending the x86 architecture, rather than some a version of it.

I do appreciate differentiate the architecturer(s) among every generation of x86 processor and x86-64 processor. But, that is not only my imagination, it is widely accepted that x86 is a 32-bit architecture introduced with 80386 processor, and also denoted as i386, Intel refer it as IA-32. This 32-bit architecture does not only point to the architecture within the 32-bit protected mode, but the entire architectures of Intel 80386 processor. Because no matter in protected mode or real mode, 32-bit registers are visible and could be utilised, and the values keep consistent across operating modes. This is not my interpretation of IA-32, such similar contents could be found on both Intel and AMD official documents.

People often use the term Chinese to refer to the entire Chinese ethnic from all over the world (they might not even know how to speak Chinese), but strictly, the term Chinese is only used to referred to the people native in China. In the similar way, people often use the term x86 to refer to all the processors whose architectures are similar or same as x86, but strictly x86 is only used to refer the architecture introduced by Intel 80386 processor, or IA-32. The fact that both x86 and x86-64 architectures co-exist on x86-64 processors, so the x86-64 is also an x86 processor. But an x86 processor might not be an x86-64 processor. Today there is no legacy x86 processor being manufactured anymore, all current x86 processor are actually the x86-64 processor. And it is the age of x86-64! — Preceding unsigned comment added by 221.9.20.9 (talk • contribs) 15:48, 18 May 2017 (UTC)

Looks to me like you should have a blog or write a book. A talk page is not the place for essays. Do you have something specific you think should change? War (talk) 15:29, 25 May 2017 (UTC)

Wikipedia.org should stand on a neutral position, but 64-bit version of x86 is a fake! It misleads readers, innocent readers from all over the world, believing that x86-64 is just x86, but it is not! Who are you? I am no interested in your age, your professional too, because you mislead them too! — Preceding unsigned comment added by 119.53.119.96 (talk) 22:43, 25 May 2017 (UTC)

Nothing here says or even slightly implies that x86-64 is "just x86". What is "non-neutral" about "x86-64 (also known as x64, x86_64, AMD64 and Intel 64) is the 64-bit version of the x86 instruction set"? What "side" is not being fairly represented thereby? Jeh (talk) 07:30, 26 May 2017 (UTC)

"VIA Technologies introduced their version of the x86-64 architecture...", why there are so many versions?

"64-bit version of x86...", "enhanced version of PAE...", this title referenced and many more, is that the versionstar invented by version genius? No, the x86-64 architecture in VIA Nano processors are the strict clone of AMD64, only with additional unrelated additional instruction sets from Centaur Technology. — Preceding unsigned comment added by 221.9.22.167 (talk) 10:14, 25 May 2017 (UTC)

If you have a specific section or sentence you think should change. Quote it and then propose what it can be changed to. We can discuss it. I won't discuss who is or isn't a genius.War (talk) 15:24, 25 May 2017 (UTC)

Your people discuss what? Only that Guy Harris stood on his/her position without being shocked, sticking to those falsies all the time, this guy and his crowds were not trying to find proofs to improve the wiki article, but find all the things to kick me out! If Wikipedia.org needs only minor editors, and prevents others from contributing or correcting, I suggest Wikipedia.org just close the door! I also found a very strange wikipedian who use Wikipedia.org as the thing to advertise this person itself and his/her training company. I found so shame about that! You know who I am really talking about! Maybe they trained too many students with such things incorrect, so they refused to change or correct them, let those lies look like true for ever! — Preceding unsigned comment added by 119.53.119.96 (talk) 22:50, 25 May 2017 (UTC)

"Only that Guy Harris stood on his/her position without being shocked, sticking to those falsies all the time" I don't wear a bra.

"I also found a very strange wikipedian who use Wikipedia.org as the thing to advertise this person itself and his/her training company." They also write drivers, as anybody who actually read their web site and understood it would know (yes, this means you either didn't read it or didn't understand it). Guy Harris (talk) 02:58, 26 May 2017 (UTC)

I don't see why the word "version" there couldn't be changed to "implementation"; as far as the x86-64 ISA is concerned, that's what Nano is. Jeh (talk) 04:25, 26 May 2017 (UTC)

Sounds good. I've done that. (Maybe they've done things differently from both Intel and AMD, in the ways AMD64 and Intel 64 differ, in which case you could perhaps call it "VIA 64" or something such as that, but, without a source for that, let's just call it an implementation. Note, BTW, that VIA repeatedly speak of it as an x86 chip....) Guy Harris (talk) 05:43, 26 May 2017 (UTC)

"Note, BTW, that VIA repeatedly speak of it as an x86 chip...."

I thank you make that correction, and I comprehend why you emphasise the "x86 chip" in the above sentence. Remember that VIA Technologies is also a vendor of ARM processors and devices based on them. They use x86 to make differentiation. Like what I explained an x86-64 processor is also an x86 processor, but an x86 processor might not always be an x86-64 processor, ..., anyway, well done, thank you! 221.9.12.193 (talk) 09:13, 26 May 2017 (UTC)

About AMD and openSUSE relationship

Under the official openSUSE wiki we are said that AMD is also a donor to openSUSE, however why openSUSE refers 64-bit into x86_64 (like Fedora, macOS, Arch Linux, Slackware), instead of amd64 (like Debian and his derivatives and Gentoo)?
202.40.137.199 (talk) 01:49, 4 June 2017 (UTC)

I don't understand the question. In particular, I can't tell if you are referring to something in the article you think should be changed, added, removed or what. War (talk) 03:19, 4 June 2017 (UTC)

Agree with War (talk · contribs · deleted contribs · logs · filter log · block user · block log). This appears not to be a question about the subject of this article but rather about the history of openSUSE's 64-bit support. And the claim that AMD is a donor to openSUSE appears to be irrelevant to the issue - they also donate to other projects. Ask over at talk:openSUSE. Jeh (talk) 04:00, 4 June 2017 (UTC)

The more interesting question might be why some Linux distributions don't call it x86_64, given that the Linux kernel mainly speaks of it as x86_64. openSuSE might just be saying "hey, that's what Linux calls it".... But that is, as Jeh notes, not particularly relevant to the article; it's not disputed that openSuSE calls it x86_64/x86-64 (a quick look at their Web site shows that). Guy Harris (talk) 04:45, 4 June 2017 (UTC)

Debian and his a part of derivatives are obviously the barely only distro calling amd64 instead of x64 by major, here I have been said the AMD processors are FATALLY power biting making the LITTLE TO MINOR market shares for the desktops and laptops, hence just also making the Linux kernel and the majorities of Linux distro calling x64 (or x86_64 in long term) from Intel, which I need to wonder why barely only a part of Debian derivatives names it to amd64 (instead of x64).124.217.188.71 (talk) 05:33, 4 June 2017 (UTC)

Again - not a concern of this article. And btw, one might also ask why Microsoft (and much of the press) picked x64. We don't know, and as far as verifiable, reliable sources go, we probably can't find out. So further discussion of this question here seems pointless. Again: maybe you should ask this over at talk:openSUSE? Or maybe at SuperUser.com ? Jeh (talk) 05:59, 4 June 2017 (UTC)

Hey pal, most Linux distros refer the x86-64 architecture as AMD64 (x86_64). Similar as IA-64 architecture, before physical AMD64 chips were realised onto the market, Linux kernel developers had already been busy with porting Linux onto this then-future 64-bit architecture, AMD64, and Debian is also one of the early distros among them. At that moment they had few knowledge that whether it would be merged into the x86 family or just another architecture alongside with it. So they just referred it as to AMD64. x64 is a term mostly used in Microsoft products, it has similar not completely same meaning as x86-64, with emphasising the 64-bit extended rather than that architecture. Because AMD64 processor is rooted onto the traditional x86 platform, during initialisation and backward support, IA-32 codes are necessary involved into the kernel. So later the developers decided the merge both x86 and amd64 architectures onto the same kernel source tree for convenience. But the Linux distro still use term x86_64 to refer the product designed for 64-bit system based on AMD64 and Intel 64 processors. Term x86-64 is used to refer to such thing, the architecture and the instruction set belonging to it. But there still exist two viewpoints

1. Standing on side of the x86 processor, the x86-64 is treated as a 64-bit instruction set extension, emphasising this 64-bit instruction set, when IA-32 software still dominated the software market.

2. Standing on the side of x86-64 processors, the x86-64 is treated as a 64-bit architecture, and the support for the x86 software is just to retain the legacy. And this viewpoint satisfy today's real situation.

So x86-64 is a 64-bit architecture alongside with 32-bit x86 architecture. 175.19.66.153 (talk) 08:57, 10 June 2017 (UTC)

First, I'd like to invite you to sign your posts. Second, please read WP:NOR. When I first started editing I made the same mistake you are making. I thought myself an expert on certain topics and edited content with the knowledge that I had. That's not good enough. You must provide references and reliable sources, regardless of your personal knowledge and experience. Wikipedia is not a blog. War (talk) 20:41, 10 June 2017 (UTC)

War, the IP to whom you responded (175.19.66.153 (talk · contribs · deleted contribs · logs · filter log · block user · block log)) is a confirmed sockpuppet of LTA Janagewen. I recommend WP:RBI, consistent with WP:DFTT. Jeh (talk) 01:14, 11 June 2017 (UTC)

Thank you for the information. I will take your recommendation.War (talk) 04:10, 12 June 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 4 external links on X86-64. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20101010233951/http://www.amd64.org/fileadmin/user_upload/pub/64bit_Linux-Myths_and_Facts.pdf to http://www.amd64.org/fileadmin/user_upload/pub/64bit_Linux-Myths_and_Facts.pdf
• Corrected formatting/usage for http://www.x86-64.org/pipermail/announce/2001-June/000020.html
• Corrected formatting/usage for http://www.h-online.com/open/features/Kernel-Log-x32-ABI-gets-around-64-bit-drawbacks-1342061.html
• Added archive https://web.archive.org/web/20050923210216/http://lxr.linux.no/ to http://lxr.linux.no/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 11:40, 3 September 2017 (UTC)

Possible Confusion: Image vs Image Caption

A small detail, I know -- I found it confusing that the caption on the X86-64 page says "Opteron, the first CPU to introduce the x86-64 extensions in 2003" while the inset image clearly shows a copyright date of 2001 printed on the CPU. It immediately begged the question "which is it: 2001 or 2003?" Documentation, both here and externally, agree that the official Opteron release date was 2003.

Perhaps the image is of a prerelease unit? The model number "OSA146DAA5BN" indicates an OEM/non-retail CPU. The OEM aspect implies it was likely produced for system builders like Dell, HP, Compaq, or Gateway. These companies would have needed some prerelease CPU's for development and initial release. That could explain the 2001 date. Except... Adding to potential confusion, this model wasn't actually released until 2005 (at least, according to the list of AMD Opteron microprocessors).

I don't know if it is possible to find an image of an Opteron CPU with a 2003 copyright date, much less of a model that was also released in 2003. I feel this would be the ideal solution. I know that copyright dates don't always align with release dates, but a 2 year difference feels extreme. A quicker-and-good-enough solution might be to drop the "in 2003" from the image caption. I could make the edit myself, but would appreciate the opinions/involvement of experienced editors.

-- GG Crew (talk) 06:36, 7 January 2018 (UTC)

I believe the copyright seen on that chip is for the AMD logo.War (talk)

+1. Guy Harris (talk) 20:04, 7 January 2018 (UTC)

Doubtful. Graphic designs that are "standalone" can be copyrighted (as the expression of a creative idea) but if they're used as part of a company or product's identity, they're trademarked or servicemarked. Either way there's still no problem here. Jeh (talk) 21:04, 7 January 2018 (UTC)

I'm not seeing a conflict. Copyright on a design can long predate the first production of a chip that implements the design. For that matter, copyright on a book manuscript can long predate its first printing. At least in the US, the copyright exists the moment it's written. Jeh (talk) 18:07, 7 January 2018 (UTC)

Correct naming - x64 and Intel 64

About the naming in the very first line; I think it should be distinguished that "x64" is NOT a correct way of referring to the 64-bit x86 (and to a certain extent neither is "Intel 64", although Intel themselves use it; it implies Intel's 64-bit Itanium which does exist, as much as some would like to forget it). I've seen many people confused why the 32-bit version is x86 and not x32 when the 64-bit is called x64; it's of course not x64 and this leads to initial confusion. I wouldn't like to see the same situation that we got when x86 was extended from a 16-bit address space pointers to a 32-bit one but it was still called "x86" and not e.g. "x86-32" to indicate the change. We indicate(d) other extentions (SSE, MMX), so why not something as big as the extention of address space? It's a small thing and you'd be right to say I'm getting hung up on naming, but I'd argue language and naming things is something very important since that's what allows us to communicate, learn and discuss; neglecting to name things correctly inevitebly leads to problems when we try to do the three things mentioned. I propose just a small change, such as "also known as x86_64, AMD64, incorrectly as x64, Intel 64" while leaving the note in place. — Preceding unsigned comment added by 85.163.18.131 (talk) 12:52, 22 July 2018 (UTC)

Who defines what's "correct"? AMD? Intel? AMD and Intel?

x64 may not be used by AMD or Intel, but it is used by Microsoft and Sun^WOracle, so, "correct" or not, it is used, and that probably should be noted.

Intel uses "Intel 64"; it doesn't imply Itanium - some people might incorrectly infer Itanium, but those people may not be aware that the Itanium architecture used to be called "IA-64", with the existing 32-bit version of x86 being called "IA-32". That meant that Intel couldn't call their flavor of x86-64 "IA-64" and they wanted to come up with some name for their flavor of x86-64; "AMD64" was unlikely to be chosen, for obvious reasons, so they imitated AMD and called it "Intel 64".

So, for better or worse, it's referred to as "x64" and "Intel 64" by organizations whose use can't simply be dismissed as "incorrect". Yes, those names may cause confusion, but that's what happens with names chosen by marketing departments; it's just something we have to live with, because Wikipedia is extremely unlikely to be able to effect any change there. Guy Harris (talk) 20:27, 22 July 2018 (UTC)

Agree with Guy Harris. x64 is very commonly used in the industry. We're not in a place to declare that it's "wrong". Jeh (talk) 04:58, 23 July 2018 (UTC)

My line of thinking was: the x86 name comes from the x86 naming of Intel's processors (80286 and 80286, 286 and 386 for short, hence x86), where does x64 come from? I don't remember an iconic line of processors using a similar naming scheme, the closest that comes to mind is the Athlon 64 line. Again, I'm being pedantic but as I already stated, there's nothing wrong with pointing wrong (or at least illogical) naming, regardless whether a couple of "industry leaders" use it. I also take back labeling Intel 64 as incorrect (although it still is illogical, Intel Architecture 32 is the 32-bit x86, IA-64 is Itanium, AMD64 is the widely implemented 64-bit x86 extention; Intel 64 = Itanium, AMD 64 = x86-64, seems simple enough for me). — Preceding unsigned comment added by 85.163.18.131 (talk) 08:15, 23 July 2018 (UTC)

I have no clue how marketing-department minds work, so I have no clue where "x64" comes from - and my curiosity about it is mild, at best. Why didn't IBM go from "System/370" to "System/380" when they added 31-bit-addressing support in 1980, but went with "System/390" in 1990 when no change that significant was made, for example? Or why did Apple go from "Mac OS X" to "OS X", several years after a non-Mac derivative, iOS, came out, rather than just going directly to "macOS"? Illogical, maybe, but, even if a lot of people might find a name illogical, I don't see any need for the Wikipedia to point that out. Guy Harris (talk) 11:15, 23 July 2018 (UTC)

To the IP: If Wikipedia were to state in its own voice that the "x64" name was "wrong" or even "illogical", regardless of reasoning, then Wikipedia would be expressing an opinion. We don't do that. See WP:NOTESSAY, which is part of our policy. We can report on opinions of recognized experts, but WP:N then requires that we give WP:DUE attention to all countering opinions, other than WP:FRINGE ones. And given the popularity of the "x64" name I'd say yours qualifies as WP:FRINGE. So, what can you do? Write your opinion on your own blog, or on a Facebook post, or maybe write it up and send it to a tech blog. But Wikipedia is not the place for your opinion or even your own reasoning. In fact, since article talk pages are not for general discussion about a topic but are supposed to be specifically for discussing improving the article, and an editor's opinion will not ever be allowed as part of the article, even the discussion here is borderline. Jeh (talk) 12:42, 23 July 2018 (UTC)

Is it also aa64?

aa64 is mentioned, for example, at https://github.com/pbatard/uefi-simple/commit/3250411a643b8967d9ed724219a33aa8af3855f7 and http://lkml.iu.edu/hypermail/linux/kernel/0008.1/0809.html. My guess is it is an abbreviation for AMD Architecture 64. And yet another abbreviation for x86-64. Is it justified to add this acronym to the x86-64 entry? — Preceding unsigned comment added by 5.102.216.121 (talk) 18:24, 11 March 2019 (UTC)

No. "mentions" in Github commits, esp from .edu , are not reliable sources. Wikipedia is not for things someone made up one day. When you see this used routinely in mainstream industry publications we can think about whether it merits as much as a mention. Jeh (talk) 18:56, 11 March 2019 (UTC)

And, at least in the uefi-simple GitHub site, it's an abbreviation for AArch64, i.e. the 64-bit ARM whatever-AArch64-and-AArch32-are (as opposed to the 64-bit ARM instruction set, which is A64, and the two 32-bit ARM instruction sets, which are A32 and T32, at least in AArch32).

In the LKML message, it appears to be x86-64/AMD64, but there's no indication where the person who sent the original message got "aa64" from - perhaps AMD used it at one point, but they mainly used x86-64 originally, and then switched to AMD64.

So, without anything more than one short thread on LKML, and with at least one place using "aa64" to refer to 64-bit ARM rather than 64-bit x86, I wouldn't include it. Guy Harris (talk) 19:08, 11 March 2019 (UTC)

Which was first?

According to the lead,

"The AMD K8 processor was the first to implement it."

According to the History section,

"The first AMD64-based processor, the Opteron, was released in April 2003."

Neither is cited. Wasn't K8 an architecture, rather than a processor? It's article suggests so, in which case would it be correct to say that "the first AMD64-based architecture was AMD K8" and "the first AMD64-based processor was the K8-based Opteron, released in April 2003"? 87.75.117.183 (talk) 00:35, 25 June 2019 (UTC)

Yes, AMD K8 was a microarchitecture, not a processor. That paragraph mainly talks about microarchitectures, so I changed it to speak of the K8 microarchitecture as being the first to implement x86-64, and gave both Opteron and Athlon64 as examples of processors using that microarchitecture. Guy Harris (talk) 03:15, 25 June 2019 (UTC)

That makes sense now. Thanks. 87.75.117.183 (talk) 05:52, 26 June 2019 (UTC)

x86_64 Is Not The 64-bit Version of x86 Instruction Set!

Please read the official documents from both AMD and Intel, both ISA manuals stat that the relationship between x86_64 and x86 are two ISA but not one! Intel calls it as Intel 64, different from IA-32; while AMD calls it as AMD64, extended and backward compatible with x86! So they are two related architectures, ISA exactly! For the similarity and the base of the design of AMD64 architecture, in Intel document, it says this thing, 64-bit mode could be treated as 64-bit mode in IA-32 architecture (page 63, Volume 1:Basic Architecture). So it isn't some a version of x86 architecture, but a 64-bit related architecture with x86. So in this viewpoint, the precise and correct description should be

x86-64 (also known as x64, x86_64, AMD64 and Intel 64[note 1]) is the 64-bit instruction set in the x86.

rather than

x86-64 (also known as x64, x86_64, AMD64 and Intel 64[note 1]) is the 64-bit version of the x86 instruction set.

The latter implies the x86 architecture is a 64-bit architecture, but in fact the x86 architecture still remains in its 32-bit form, had never been changed, reserved for later development in the future! Word "in" could be more used to describe the relationship between them two, the related two things rather than one! 119.53.106.136 (talk) 02:21, 4 January 2020 (UTC)

If we look at Intel 64 and IA-32 Architectures Software Developer’s Manual, Volume 1: Basic Architecture, in chapter 2, "Intel 64 and IA-32 Architectures", Intel just speaks of the "Intel Instruction Set Architecture", not of multiple instruction set architectures. Chapter 5, "Instruction Set Summary", doesn't have separate sections for IA-32 and Intel 64 instructions; they just indicate which processors support which "instruction groups", e.g. "All Intel 64 and IA-32 processors" support the "General Purpose" instructions. (The table is a bit confusing, as it has a bunch of "instruction groups", the instructions in which are supported by all 64-bit processors but not all 32-bit processors, so those groups list only the 32-bit processors that support them as well as some but not all 64-bit processors.)

And if we look at the three sections of Volume 2: Instruction Set Reference, there's only one description of each instruction - there aren't separate descriptions for IA-32 and Intel 64, they just have, for each instruction, a table giving various encodings for the instruction, the behavior of the instruction with that encoding (giving, for example, the operand length), and columns indicating whether a given encoding is valid in 64-bit mode and whether it's valid in 32-bit compatibility/legacy/"this is all you get with an IA-32 processor" mode. (The description of the INC instruction notes that certain encodings aren't valid in 64-bit mode because they're interpreted as a REX prefix in that mode; however, there are other encodings for the same operation.)

So Intel's documentation doesn't seem to speak of two instruction sets, just one instruction set, which, in Intel 64 processors, has multiple modes - 64-bit/long mode, 32-bit compatibility mode, and 32-bit legacy mode (the latter is the only available mode in IA-32 processors).

AMD64 Architecture Programmer’s Manual, Volume 1: Application Programming speaks of "the AMD64 architecture" as a "64-bit, backward-compatible extension of the industry-standard (legacy) x86 architecture". It speaks of "the AMD64 instruction set architecture"; it says nothing about any other instruction set, whether it's "IA-32" or whatever.

So AMD's documentation doesn't explicitly speak of two instruction sets, either, although they try to draw more of a distinction between 32-bit and 64-bit machines - not surprising, given that the 64-bit mode and its additions to the instruction set were their creations, so they'd want to promote it.

This is similar to other ISAs that have 32-bit and 64-bit modes, with the exception of ARM - there are 32-bit and 64-bit modes. 64-bit mode in x86 adds some additional capabilities that aren't available in code for 32-bit mode, such as additional GPRs and PC-relative addressing, so there's a bit more difference between the two modes than is the case for SPARC/MIPS/PA-RISC/Power ISA/{IBM mainframe}, but not a lot more - the instruction encodings are 99 44/100% the same. (ARM is an exception; ARM themselves speak of three instruction sets in AArch64 - A32, the traditional 32-bit ARM; T32, with Thumb and Thumb-2 encodings, and A64, which is significantly different from A32, given that, for example, it gets rid of most if not all of the predicated execution stuff.) Guy Harris (talk) 03:14, 4 January 2020 (UTC)

Thank you for your reply, but I just reserve your viewpoint! The only thing you emphasised for years, that you believe the x86 architecture has already been formed in its 64-bit version, and you believe the AMD64 architecture is just one version of x86! But in fact, it isn't! AMD just developped a 64-bit prototype of x86 architecture, leaving the original x86 without touched or even modified. From this very viewpoint, the instruction set belonging to the long mode could only be counted as the 64-bit instruction set of x86-64, or 64-bit instruction set in x86. One could not use the results as the reasons! Instruction Set Architecture is not identical to Instruction Set, the x86-64 is not only additional instruction set like SSE, AVX and so forth, it is a completely an Instruction Set Architecture, standalone above x86. So one could not say it is merely the 64-bit version of x86 instruction set, and in fact it is not! 119.53.106.136 (talk) 03:37, 4 January 2020 (UTC)

There are several instruction sets that didn't start out as 64-bit instruction sets and to which 64-bit support was added by adding a 64-bit mode - MIPS, SPARC, PA-RISC, PowerPC/Power ISA, System/3x0. In what way do they differ from x86, other than that, in 64-bit mode on x86, there are additional operand encodings to support 8 more GPRs and PC-relative addressing, there are a few encodings of existing instruction that aren't supported (because they're used for REX, the prefix that enables the previous feature), and segmentation isn't fully supported, whereas in 64-bit mode in those other ISAs, there aren't significant new features available only in 64-bit mode (as far as I know)? Guy Harris (talk) 04:00, 4 January 2020 (UTC)

What x86-64 is

x86-64 (also known as x64, x86_64, AMD64 and Intel 64[note 1]) is the 64-bit version of the x86 instruction set. — Preceding unsigned comment added by JustAUser201468 (talk • contribs) 06:49, 21 June 2021 (UTC)

Yes, that's what it is, and what the article says it is. Guy Harris (talk) 07:04, 21 June 2021 (UTC)

Rename the article to "x86_64"

Instead of the article being "x86-64" with a dash and listing "x86_64" as an alias, we should do it the other way around and have "x86_64" with an underscore be the article name with "x86-64" listed as an alias. In the vast majority of places I've seen the architecture written down it is "x86_64", not "x86-64". I assume this is mostly the case because "-" cannot be used in an identifier in programming languages. However, outside of the actual content of programs, it seems that programmers almost always use "x86_64" when chatting or writing documentation. So I propose we rename the article to "x86_64". Aaronfranke (talk) 06:06, 31 August 2021 (UTC)

1) This isn't the only article whose title cannot be used as an identifier in most programming languages (COBOL doesn't mind "-" in identifiers). 2) I haven't noticed the vast majority of non-code places referring to "x86_64". 3) "x86-64" was the original name that AMD gave it, later going with "AMD64" as, presumably, a branding move (with Intel following up with "Intel64"). So I propose we leave well enough alone. Guy Harris (talk) 07:30, 31 August 2021 (UTC)

Oddities in the "Physical address space details"

Current AMD64 processors support a physical address space of up to 248 bytes of RAM, or 256 TiB.[18] However, as of 2020, there were no known x86-64 motherboards that support 256 TiB of RAM.

Aside from the "248 bytes" thing (LOLWUT?), those kind of address spaces aren't now, and probably will never be available on a single motherboard. Most home users still buy computers with 8 or 16GB of ram on a regular basis despite modern operating systems performing far better with 64GB and above unless they've just not bothered to implement memory caching of hot data. Intel processors support using PCIe lanes as transparent links or other types of bridges to other motherboards and devices for clustering purposes, and sharing of memory spaces that aren't necessarily board-local. So no, a single motherboard doesn't support 256TB, but something like a 3rd generation scalable Xeon in 2S configuration could have 12TB on a board, and multiple lanes loaded up with high speed interconnects to other boards. Depending on the configuration of the PCIe links you could probably expose 256TB to a single processor within a half-filled rack of blade servers, and I'm just spitballing there because things have probably progressed quite a bit since I last read a processor spec sheet and the method of configuring this at the hardware level in detail. There's a reason 57-bit addressing is already a thing in the architecture docs and I guarantee it isn't because nobody needed it fast.

Mentioning that it can't be done on a single board is pointless; they don't make ram modules large enough to fill out the number of slots that can be crammed within the very short distance to the processor required because of timing issues as of 2022. E7v4 Xeons capable of 8S configurations managed tons of ram with memory riser boards; the cost was that the memory controllers were moved out onto the risers, the boards needed to be fully populated, and the RAM ran a decent downclock below the standard 2133MHz speed of DDR4 so timing could work.A Shortfall Of Gravitas (talk) 13:26, 22 April 2022 (UTC)

COMPUNITS

@Locke Cole: COMPUNITS reads "Do not assume that the binary or decimal meaning of prefixes will be obvious to everyone. Explicitly specify the meaning of k and K as well as the primary meaning of M, G, T, etc. in an article ( is a convenient helper). Consistency within each article is desirable, but the need for consistency may be balanced with other considerations." My edit made the meaning obvious. Yours achieved the opposite. Dondervogel 2 (talk) 16:43, 12 April 2021 (UTC)

From WP:COMPUNITS:

The IEC prefixes kibi- (symbol Ki), mebi- (Mi), gibi- (Gi), etc., are generally not to be used except:

• when the majority of cited sources on the article topic use IEC prefixes;
• in a direct quote using the IEC prefixes;
• when explicitly discussing the IEC prefixes; or
• in articles in which both types of prefix are used with neither clearly primary, or in which converting all quantities to one or the other type would be misleading or lose necessary precision, or declaring the actual meaning of a unit on each use would be impractical. —Locke Cole • t • c 16:44, 12 April 2021 (UTC)

I'm staring at a 2021 edition of the Intel arch manual. Section 3.4.5 Protected Mode Memory Management - Segment Descriptors talks about segment sizing... (Apologies if I linked to the wrong doc, I just pulled it from the article references. I have the combined version of it and don't feel like searching the web for a link to the current one at the moment).

Specifies the size of the segment. The processor puts together the two segment limit fields to form a 20-bit value. The processor interprets the segment limit in one of two ways, depending on the setting of the G (granularity) flag:

• If the granularity flag is clear, the segment size can range from 1 byte to 1 MByte, in byte increments.
• If the granularity flag is set, the segment size can range from 4 KBytes to 4 GBytes, in 4-KByte increments.

Note that this source is used as a reference multiple times in the article... different volumes of it, anyway. If the manufacturer of the processor is calling them MB / KB / GB, we should follow suit. If Intel jumps on the boat with GiB and such to make their manual slightly more incomprehensible and 100% more annoying to the 10 systems programmers who still read it, we should follow suit in the article. I personally prefer AMD right now, Intel threw their cost / performance advantage away years ago, but I didn't check their manual because they're technically still an "Intel Compatible" processor which makes them secondary in my mind even if that doesn't mean anything anymore like it did back when there were 5 brands of "kinda Intel compatible" chips floating around. Given that they came up with X86-64 as it's currently used, maybe they should be used as the authoritative source here. I bet they're not using GiB in their processor docs though. They certainly don't in their GPU arch / optimization docs.

Yes the small % of the public that uses linux as a desktop OS will have issue with it. They also use ancient AT&T syntax assembly language and opcode postfixes that don't exist in the official docs for Intel and ARM processors despite each of them having their own defined syntax, which makes their opinion invalid in the "what should programmers do" area, which is kinda what a lot of this article is about.

Yes, Intel spelled byte out, so does the IEC prefix. If they'd meant to they'd have written GiByte which miraculously still sounds less stupid than gibibyte. The only benefit the IEC system would have had is that I could pedantically tell people they should be calling bytes IBIBYTES online but it seems to be defined in powers of 1024 if that article is correct. Kind of odd since I thought the whole purpose of the new prefix set was to indicate base 2, but I'm just going by that article and I'm sure it's correct given how fervently people seem to go around changing everything else to use the prefixes despite protests from everybody else on the planet. A Shortfall Of Gravitas (talk) 14:21, 22 April 2022 (UTC)

References