Talk:64-bit computing

This  level-5 vital article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Computing: Software High‑importance 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.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing High This article has been rated as High-importance on the project's importance scale. This article is supported by WikiProject Software (assessed as High-importance). This article is supported by Computer hardware task force (assessed as High-importance).

This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later.

Archives

Index Archive 1 Archive 2

This page has archives. Topics inactive for 60 days are automatically archived by Lowercase sigmabot III.

It would be good if statements like this

Currently, most proprietary x86 software is compiled into 32-bit code, with less being also 
compiled into 64-bit code (although the trend is rapidly equalizing)

were dated so the reader knows when "Currently" was. — Preceding unsigned comment added by Jim Evans (talk • contribs) 18:43, 13 April 2010 (UTC)Reply

That statement has disappeared from the article sometime between 2010-04-13 and 2026-03-16, probably became it's no longer true. Guy Harris (talk) 05:31, 17 March 2026 (UTC)Reply

There seems to be an incompatibility here. On the one hand, in the section 32-bit vs. 64-bit it says 'A 64-bit processor has backward compatibility and will handle most 32-bit software', while in the timeline section it says '2019: Apple releases macOS 10.15 "Catalina", dropping support for 32-bit Intel applications'. Perhaps both are correct (I know the second one is), but some clarification (maybe in regard to what is meant by 'most') would seem to be in order. This is not a trivial matter: I've been delaying upgrading my Mac as I have some 32-bit software I want to go on being able to use. --Brian Josephson (talk) 18:12, 2 December 2020 (UTC)Reply

A 64-bit processor with an instruction set that adds 64-bit support to an existing 32-bit instruction set, so that there's a 32-bit instruction set with which to be backward compatible, could be made capable of supporting an operating system that can run the older 32-bit code as well as 64-bit code. Most such processors are capable of that, and some of those processors are also capable of running 32-bit operating systems by running completely in 32-bit mode, but there may be some that aren't; I suspect Apple might not have bothered to provide support for 32-bit code in later A-series processors and in the M1.

An operating system running on that processor, however, might not include support for 32-bit programs. That's the case for iOS 11 and later releases of iOS (and thus for all releases of iPadOS, which started with iPadOS 13), and that's the case for macOS Catalina and later releases of macOS.

So there's no inconsistency (which is a better term for what you're describing than "incompatibility") in the article. The first quote describes the capabilities of some 64-bit processors (it may need to be edited to make a less definitive statement); the second quote describes what capabilities a particular version of a particular operating system offers. Guy Harris (talk) 19:09, 2 December 2020 (UTC)Reply

Thanks for the clarification both here and on the article page. --Brian Josephson (talk) 19:54, 2 December 2020 (UTC)Reply

@Guy Harris and Joedf: I see there was a minor discussion above about exabytes vs exbibytes, and I note this article is rife with IEC units which appears to go against the guidance at WP:COMPUNITS. I checked one of the sources (AMD64 Programmer's Manual Volume 2: System Programming) and on page 24 (page 88 of the PDF) in section 2.2.1 - Memory Addressing, there is this passage (highlighted portions added for clarity):

Virtual-Memory Addressing. Virtual-memory support is expanded to 64 address bits in long mode.

This allows up to 16 exabytes of virtual-address space to be accessed. The virtual-address space supported in legacy mode is unchanged.

Physical-Memory Addressing. Physical-memory support is expanded to 52 address bits in long mode and legacy mode. This allows up to 4 petabytes of physical memory to be accessed. The

expanded physical-memory support is achieved by using paging and the page-size extensions.

This source is, by no means, historical, and was revised as recently as March of this year. I haven't checked the other cited sources, but if our sources are using petabyte, exabyte, terabyte (and the associated PB, EB, TB) then our article should as well (notwithstanding the WP:COMPUNITS guidance from MoS which really ought to be enough on its own, but just saying, the sources are also not using IEC units). In so far as kilobyte (KB), megabyte (MB) and gigabyte (GB) vs. the IEC prefixed variants, consider JEDEC memory standards. If there is no reasonable objection to making the article consistent with the sources I'll make the switch so our article can conform with standard usage in technical documentation (see this Microsoft developer article on memory limits in the various versions of Windows and Windows Server for examples of GB and TB (vs GiB and TiB in our article)) and in the larger media. —Locke Cole • t • c 18:21, 14 April 2021 (UTC)Reply

Implemented the correction. —Locke Cole • t • c 16:56, 16 April 2021 (UTC)Reply

For reasons that will forever confuse me, there appears to be some misunderstanding about MOS:COMPUNITS. After correcting the article in 2021, it was changed again without discussion. I've restored it for the same reasons previously given above. —Locke Cole • t • c 06:38, 16 July 2024 (UTC)Reply

How large is a screen resolution: 8, 16, 32, 64 or ... bit? How do you define a 32 / 64 Office API (any API)? I can't find anything pertinent with Google, neither here in the Wikipedia; does someone know where to find pertinent information on bitness, and why Microsoft Office made such a mess with it's API? Or can someone add that info to the appropriate article(s)? Alien4 (talk) 16:38, 2 November 2022 (UTC)Reply

Following is weird & misleading. Most high performance 32-bit and 64-bit processors (some notable exceptions are older or embedded ARM architecture (ARM) and 32-bit MIPS architecture (MIPS) CPUs) have integrated floating point hardware, which is often, but not always, based on 64-bit units of data."

Far more accurate would be: "High-performance microprocessors of the 1980s had 32-bit integer units and mostly 64-bit floating point units, usually implemented as separate coprocessor chips, as seen in MIPS architecture, Hewlett-Packard's PA-RISC, Sun's SPARC, Intel X86, Motorola 68000 series. Intergraph Clipper architecture, Motorola 88000, and Intel Intel i860did integrate integer and floating point units, although none were very successful in the market. By the 1990s, 64-bit integer and floating point units were typically integrated on one chip."

Comment: the 1980s higher-performance RISC chips had at least 16 64-bit floating point registers. The early Clippers had 8, the Motorola 88000 used the same 32 32-bit register file for both integer and floating point. In either case, some floating point codes really needed more registers. JohnMashey (talk) 06:12, 27 February 2026 (UTC)Reply