Talk:64-bit computing

General discussion for bit size??

This appears to be among the most extensive of the bit size articles, it would be good to put the general arguments for all bit sizes into one mother article, with specific stories about specific machines and technology historiesfor each bit size. For example, PCs and minis all tripped over the 64k barrier in the 1980s, while PCs were transitioning to 64 bit processors but not yet 64 bit operating systems as of 2009. Bachcell (talk) 20:01, 28 August 2009 (UTC)

PCs are still transitioning to 32-bit operating systems, and will be forever. Some people even go back to 16-bit. You could say we're "transitioning" forever. On the other hand, my PC got a 64-bit OS as of 2003. People still running 32-bit are just lame. 72.40.152.209 (talk) 06:03, 13 January 2010 (UTC)

Pros and cons again

I think the last paragraph in the Pros and cons section needs to goor be reworded. It is simply not true that most proprietary software is 32bit only while open-source/risc has been using this for years, there is a great deal of proprietary software available in 64-bit varieties today. It is also quite clearly an attempt to put in a jab at proprietary software. Threesevenths (talk) 20:04, 28 November 2009 (UTC)

I've changed the last paragraph slightly so as to be less biased towards open-source software. Xtremerandomness (talk) 18:23, 29 December 2009 (UTC)

Technical Error - physical vs virtual address size

Under "Limitations"

"For example, the AMD64 architecture has a 52-bit limit on physical memory and currently only supports a 48-bit virtual address space[1]."

This is factually incorrect. Virtual address space is always larger than physical address space. The author of this section accidentally reversed the numbers. This should read:

"For example, the AMD64 architecture has a 48-bit limit on physical memory and currently only supports a 52-bit virtual address space[1]."

I am making the edit to correct this. Hardwarefreak (talk) 04:43, 11 January 2010 (UTC)

Sorry but you are mistaken and I have reverted your edit.

First, virtual address space is not necessarily larger than physical. As far back as the PDP-11, for example, virtual was 64 KB, physical up to 4 MB.

An x86 system running in PAE mode allows a 4 GB v.a.s. but a 64 GB physical space in the first implementation, and more physical space in later implementations - look at the article on Physical Address Extension. Address translation there takes 32 bits of virtual address in, 36 bits of physical bits out.

And as for x64, it indeed translates a 48-bit virtual address into a 52-bit physical address (40 bits from the page table entry, 12 bits from the byte offset). If you read the documentation cited, or even the Wikipedia page on x86-64, you will see this.

Now you are probably wondering, how can it make sense to have virtual smaller than physical? The reason this makes sense is that while the processor can only address 48 bits of virtual address space at one time, it can address a different 48 bits' worth of virtual address space for every different contents of CR3.

Let's take the specific example of x64 Windows, which only currently populates 16 TB of the 256 possible TB of v.a.s. Kernel mode uses the high 8 TB, and the currently-mapped process uses the low 8 TB. A process context switch includes a reload of CR3, which means a different set of page tables and a different mapping of 8 TB of per-process v.a.s. for each process. In other words, v.a.'s from 0 to 7FF`FFFFFFFF are remapped and so reused for every process, much in the manner of 7-digit phone numbers being reused in each area code. Therefore the total v.a.s. that can be defined is not just 16 TB, but 8 TB + (nProcesses x 8 TB) - a number limited only by backing store.

See also Windows Internals by Russinovich et al for confirmation. Jeh (talk) 07:58, 13 January 2010 (UTC)

ISA physical address space is silicon implementation dependent. So far I cannot find any online documentation for any x86-64 implementation that has anything other than a 40 bit address space and 48 bit virtual space. Please quote an online freely available primary source (i.e. AMD itself) that states an implementation with a 52 bit physical address space and 48 bit virtual address space. I'm not arguing such an implementation doe not exist. I'm simply asking for a source of this information, as I'm unable to locate such a document online. Please don't refer me to another Wikipedia article as they are not primary sources (if they were we'd not be having this discussion).  ;) Hardwarefreak (talk) 01:38, 14 January 2010 (UTC)

Architecture Programmer's Manual Volume 2: System Programming. page 115:

The x86 architecture provides support for translating 32-bit virtual addresses into 
32-bit physical addresses (larger physical addresses, such as 36-bit or 40-bit 
addresses, are supported as a special mode). The AMD64 architecture enhances this 
support to allow translation of 64-bit virtual addresses into 52-bit physical 
addresses, although processor implementations can support smaller virtualaddress
and physical-address spaces.

That takes care of the 52-bit physical address. It so6unds like we're talking about a 64-bit virtual address, but Figure 5-1 on page 117 shows that although the VAs are indeed 64 bits wide, the highest bits of the VA are not actually translated. Then at the top of page 118:

Currently, the AMD64 architecture defines a mechanism for translating 48-bit virtual
addresses to 52-bit physical addresses. The mechanism used to translate a full 64-bit 
virtual address is reserved and will be described in a future AMD64 architectural
specification.

Table 5-1 on page 118 also specifies a maximum physical address of 52 bits.

Figure 5-17 on page 130 confirms. 48 bits come from the virtual address, 52 bits of physical address come out. Figure 5-21 shows the PTE format: There are 40 bits of "physical page base address", to which are appended the 12 bits of "physical-page offset" (byte offset in page) from the original VA. Hence 52 bits total.

"Sign extend" refers to the fact that bits 48-63 of the VA must be a copy of bit 47, in a manner similar to sign extension in two's complement arithmetic, when converting (say) a signed byte to a signed word or longword.

I know you're asking for "an implementation" but we are talking here about the ISA, not the limitations of any implementation. You claimed "virtual space is always larger than physical" but there is no requirement for that, nor is it necessarily desirable. Incidently on x86 without PAE they are the same size - but that is not because it's a "32-bit" processor, it's more or less an accident of the page table format, which happens to provide 20 bits of physical page number. If it had provided 19 bits then PAS would be smaller than VAS; when it provides 24 bits (as it does in PAE mode) then PAS is larger than VAS. And while there may in fact be no x64 implementations that support more than 40 bits of physical address space, there are most certainly x86 implementations and whole systems that support 64 GB RAM; thus there are indeed real-world examples of virtual space being smaller than physical. Jeh (talk) 02:02, 14 January 2010 (UTC)

x86/Windows-centric???

It seems that some of the content is phrased as being generally applicable to 64bit systems, but appears to be specific to Windows and/or x86 systems. I suspect that this might be a result of the article trying to encompass so many facets of 64 bit systems. Eg, processor design, databus width, cpu registers, memory addressing etc, and the way that 64bit OSes are implemented, 64bit/32bit kernels, 64bit/32bit apps, memory limitations, how they might deal with legacy 32bit apps. Someone with a better understanding of these thing might be better placed to edit this article. Perhaps there could be a disentangling of 64 bit hardware and 64 bit Operating Systems, and within those sections a discussion of the way the architectures are/could be implemented eg what parts might be 64 bit and/or take advantage of 64 bit architecture. Real world examples are very useful for understanding, but need to be given a full context.60.240.207.146 (talk) 01:38, 16 January 2010 (UTC)

Plain English?

How about some?

Thanks...