|This is the talk page for discussing improvements to the X86-64 article.|
|WikiProject Computing / Hardware||(Rated C-class, High-importance)|
|Threads older than 30 days may be archived by.|
Diagram change requested
Ok, who's good with editing these SVG files? I would like to request that Image:AMD64-canonical--48-bit.svg and Image:AMD64-canonical--56-bit.svg be modified to include the text "(not to scale)" under the text "Noncanonical addresses".
If we were not trying to be so encyclopedic we could write "very much not to scale" instead. In the 48-bit diagram, the two canonical halves would be each 1/131072 of the total height. i.e. a tiny fraction of a pixel high! In the 56-bit picture the two halves would each be 1/512 of the total height, which still would not be an entire pixel on most screens... but it would be getting close to one.
Short forms of registers
Even without the excessive lower-byte registers, the table is not working for me. It is not the case, for example, that there is one register of which EIP is the low 32 bits and RIP is the high. But that's what the table/diagram shows. I think all of the short forms should be removed in the short term. e.g. RIP would just show RIP. Jeh (talk) 21:18, 14 February 2014 (UTC)
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.
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?
- 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)