Talk:X86-64

Long mode vs. real mode and virtual 8086 mode

The Long mode section contained this

Real-mode programs and programs that use virtual 8086 mode at any time cannot be run in long mode unless they are emulated in software.

Which was deleted by Someone not using his real name (talk · contribs) with a rather WP:POINTy edit comment.

I have restored it. Here's why: The method described in Virtual 8086 mode is

The addition of VT-X has added back the ability to run virtual 8086 mode from x86-64 long mode, but it has to be done by transitioning the (physical) processor to VMX root mode and launching a logical (virtual) processor itself running in virtual 8086 mode.

Westmere and later Intel processors usually[c] can start the logical processor directly in real mode using the "unrestricted guest" feature (which itself requires Extended Page Tables); this method removes the need to resort to [the nested] virtual 8086 mode simply to run some MS-DOS application.

See, you're still not running the real mode or virtual 8086 mode app under long mode! Of course you can run, as in start, such a program while using a long mode operating system... as long as you do it by creating a whole new virtual processor, which itself can run in the desired mode (Virtual 8086 or real mode). Heck, you could also have a second machine handy running an x86 OS and send the old binary to it for execution...

...But the restriction on running such programs in or under long mode is still there. As it says in the AMD doc (whose cite I just updated), page 11, note 3:

Long mode supports only x86 protected mode. It does not support x86 real mode or virtual-8086 mode.

I did acknowledge the possibility of getting around this restriction via VT-X, by appending this to the restored sentence:

However, such programs may be started from an operating system running in long mode on processors supporting VT-X, by creating a virtual processor running in the desired mode.

I believe this covers it, better than the original sentence did, and certainly better than the article did without that sentence.

However, I'm not sure what the big deal is about VT-X here. You could run a DOS app under x64 Windows (or, I believe, Linux) by using any of a number of virtual machine hosts—DOSbox having been specifically promoted for that purpose—long before VT-X existed. Jeh (talk) 07:19, 18 February 2014 (UTC)

Thanks for fixing this. I'd just like to point out that my edit wasn't pointy. The material was unsourced, and it's (original) claim is not supported even by the sources you brought up, specifically "Real-mode programs and programs that use virtual 8086 mode at any time cannot be run in long mode unless they are emulated in software." Besides the vagueness as to what is a program (does an OS kernel/loader qualify? you can surely start a x86_64 kernel in real-mode then switch to long mode so "at any time" doesn't seem to apply in this case), and (2) "unless they are emulated in software" is also false even for the typical scenario, as there are other ways, such as hardware-assisted virtualization which isn't normally defined as "emulated in software". That DOSbox doesn't do it in any other way is irrelevant, really. Someone not using his real name (talk) 10:52, 18 February 2014 (UTC)

Hi. There is a problem that I saw in the original edit. Let me explain with an analogy. Take OpenShot Video Editor for example. It runs on Linux only. Suppose someone comes round and say it runs on Windows. I say, "oh yeah?" He says, "yeah, just download VirtualBox and Ubuntu and you are set! It runs on Windows." Wrong! "To run on an [OS name]" implies that if you take away the said OS, it won't run! Take away Windows out of this config and I can still run OpenShot straight on Ubuntu. Take away Ubuntu out of this config and OpenShot binary won't run on my computer, no matter what.

So when you virtualize a processor, the software is not running in the long mode. It is running in real mode. Take away the long mode and the program still works. Take away the real mode and no, it won't run. You can see the weak point in my argument right now: "...unless they are emulated in software." I should've removed this too, right?

Best regards,

Codename Lisa (talk) 01:13, 19 February 2014 (UTC)

Regarding the example of an OS loader... oh, please. You know perfectly well what is meant by "programs." But if you insist, then I will insist on pointing out that an OS loader that starts in real mode, loads the 64-bit OS, and then switches to long mode before transferring control to the OS is still not running its real-mode code under long mode. So that isn't a valid counterexample. Jeh (talk) 01:38, 19 February 2014 (UTC)

Lead image suggestions?

I think we should put an image in the lead section. Any ideas? The supercomputing cluster adoption chart looks best in its own section. Maybe we could use the logos of AMD64 and Intel64, or a photo of the first x86-64 processor (AMD Opteron). What would you suggest? Sofia Koutsouveli (talk) 01:27, 20 March 2014 (UTC)

Hello there! If you ask me, that would be an image of a processor. — Dsimic (talk | contribs) 01:42, 20 March 2014 (UTC)

Hi. I'm thinking about low-resolution versions of "AMD64 Architecture Programmer’s Manual" and/or "Intel 64 and IA-32 Architectures Software Developer’s Manual", if that's allowed by the law. Dannyniu (talk) 03:10, 14 June 2014 (UTC)

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)

Jangewan 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	39 to 42 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)