|This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.|
|Archive 1||Archive 2|
- 1 Current 64-bit microprocessor architectures
- 2 Modern games and 64-bit
- 3 Decimal digits
- 4 Archiving
- 5 General discussion for bit size??
- 6 Pros and cons again
- 7 Technical Error - physical vs virtual address size
- 8 x86/Windows-centric???
- 9 Confusing Mixture of SI and IEC binary prefixes
- 10 Plain English?
- 11 Usage statistics?
- 12 Java JVM Startup and Performance
- 13 Purpose of Article
Current 64-bit microprocessor architectures
Is this list supposed to list 64-bit ISAs or implementations of 64-bit ISAs? It looks like it might need some tweaking and I don't want to delete the wrong content. Rilak (talk) 09:05, 4 July 2008 (UTC)
Modern games and 64-bit
What about 3D rendering and Photoshop. Does 64-bit speed up applying those "effects" in Photoshop that take forever on a very large image?
Can we get some PRACTICAL answers rather than this scientific jargon? This is an encyclopedia after all!
Maybe I missed it, but many general readers will want to translate/understand 64-bits in terms of decimal digits, which is what they know (20 if my math is correct) ...--Billymac00 (talk) 05:24, 22 November 2009 (UTC)
Does anyone object to me setting up automatic archiving for this page using MizaBot? Unless otherwise agreed, I would set it to archive threads that have been inactive for 60 days.--Oneiros (talk) 13:02, 21 December 2009 (UTC)
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 histories for 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. 220.127.116.11 (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)
Technical Error - physical vs virtual address size
"For example, the AMD64 architecture has a 52-bit limit on physical memory and currently only supports a 48-bit virtual address space."
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."
- 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)
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)
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.18.104.22.168 (talk) 01:38, 16 January 2010 (UTC)
Confusing Mixture of SI and IEC binary prefixes
This article uses a confusing mixture of JEDEC prefixes (e.g., gigabyte) and IEC prefixes (e.g., gibibyte) to mean 1024 MiB. The "History" section prefers gigabyte, while the section following uses gibibyte, though both terms are intended to mean the same thing. Either all terms should use gigabyte to mean 1024 megabytes (and 1 MB = 1024 kB and 1 kB = 1024 B), or all terms should use gibibyte to mean 1024 MiB and gigabyte to mean 109 bytes. Kaiserkarl13 (talk) 18:12, 4 May 2010 (UTC)
How about some?
Java JVM Startup and Performance
I rewrote the text on Sun JVM 64 bit vs 32 startup for several reasons:
- The fact that 64 bit applications (especially those that do not take advantage of 64 bit features) may be slower than comparable 32 bit applications is not specific to Java.
- The reference to http://java.sun.com/docs/hotspot/HotSpotFAQ.html#64bit_compilers does not support the original text that says that "Sun's 64-bit Java virtual machines are slower to start up than their 32-bit virtual machines because Sun has only implemented the "server" JIT compiler (C2) for 64-bit platforms."
- If we're going to talk about 32 bit vs 64 bit (the section containing this text) then it would be much more useful to most readers to talk about some of the other features of Java in a 32 / 64 bit world (like the fact that compiled Java programs are portable to 32 or 64 bit virtual machines). 22.214.171.124 (talk) 11:57, 9 July 2010 (UTC)
Purpose of Article
The writer's purpose for writing an article may be different from the reader's purpose for looking up the article. I looked up the article to see if 64-bit processing was hardware-based or software-based. (Was it a new form of hardware in the machine that makes it 64-bit, or a new software trick being applied to commonly existing hardware?)
While the article is well-written with many interesting and even fascinating details, explanations and timelines, it might be improved with either a paragraph discussing whether a 32-bit machine can be turned into a 64-bit machine (and vice-versa) or a clear link to an article that addresses that question. (Some 32-bit applications will not run in 64-bit environments even if 32-emulation applications are available. Most 32-bit emulators only work on 99% of applications.) If such links or explanations existed as of 8/9/2010, I did not spot them, although I did read enough of the article to spot the size in petabytes of the current addressing capabilities. —Preceding unsigned comment added by 126.96.36.199 (talk) 15:11, 9 August 2010 (UTC)
Take a look at "The Long Road to 64-bits." A 32-bit computer cannot be a 64-bit computer, but most 64-bit micros are actually better called 64/32-bit, selected by mode bits. With the exception of the DEC Alpha, the earliest such CPUs (such as MIPS R4000, ~1991) ran existing 32-bit kernel and user code. Later OS releases were upgraded the kernel to 64-bit internally, but supported libraries and interfaces to run both 32-bit and 64-bit user applications, as many existing applications had no need of the 64-bit addressing. JohnMashey (talk) 02:33, 20 February 2011 (UTC)