From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / Hardware (Rated C-class, High-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 High  This article has been rated as High-importance on the project's importance scale.
Taskforce icon
This article is supported by Computer hardware task force (marked as High-importance).
edit·history·watch·refresh Stock post message.svg To-do list for X86-64:
  • Restore the table listing AMD64 registers, please see this edit which removed it from the article.

Diagram change requested[edit]

Ok, who's good with editing these SVG files? I would like to request that Image:AMD64-canonical--48-bit.svg and Image:AMD64-canonical--56-bit.svg be modified to include the text "(not to scale)" under the text "Noncanonical addresses".

If we were not trying to be so encyclopedic we could write "very much not to scale" instead. In the 48-bit diagram, the two canonical halves would be each 1/131072 of the total height. i.e. a tiny fraction of a pixel high! In the 56-bit picture the two halves would each be 1/512 of the total height, which still would not be an entire pixel on most screens... but it would be getting close to one.

Maybe we just need a "relative sizes not to scale" notation at the bottom of the whole thing. Jeh (talk) 09:15, 22 January 2014 (UTC)

To Codename Lisa: Yeah, that'll do :) Jeh (talk) 11:03, 22 January 2014 (UTC)

Short forms of registers[edit]

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[edit]

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?[edit]

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)