Talk:64-bit computing

When?

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.

Inconsistency with use of 'Exabyte / Exbibyte' term or its equivalency

I've notice the following two sentences stating somewhat conflicting information:

1. In the introduction paragraph:

   Hence, a processor with 64-bit memory addresses can directly access 2⁶⁴ bytes (=16 exabytes) of byte-addressable memory.

2. In "Limits of processors":

   In principle, a 64-bit microprocessor can address 16 EiBs (16 × 10246 = 2⁶⁴ = 18,446,744,073,709,551,616 bytes, or about 18.4 exabytes) of memory.

Perhaps I am misunderstanding something here, but seems to me that 264 == 264, bytes are bytes, exabytes are exabytes. Same values, same units and thus the final result should have the same value if the units are same. Either both are ~18.4 Exabytes (EB), or 16 Exbibytes (EiB), something else? As the byte unit is the common ground for both Magnitude systems (1000 vs 1024), 264 == 18446744073709552000 == 16 * 10246 ≈ 18.4 × 10006 ≈ 18.4 × 1018, then the first sentence was probably meant to use exbibyte instead of exabyte. Mainly, 16 Exbibytes ≈ 18.4 Exabytes. However for consistency, the values should be changed and use the same term. Comments? Joedf (talk) 16:13, 30 October 2019 (UTC)

Not sure what WP:COMPUNITS dictates here. Guy Harris (talk) 16:57, 30 October 2019 (UTC)

Requested move 26 December 2019

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: Not moved. Others will be moved to be in line with this one.  — Amakuru (talk) 16:42, 2 January 2020 (UTC)

---

64-bit computing → 64-bit – Consistent with other "n-bit" articles. WP:COMMONNAME plus WP:TITLECON outweigh WP:NOUN. (Tried to request a technical but quickly withdrawn after finding out the previous discussion.) Nemoschool (talk) 20:36, 26 December 2019 (UTC)

• Oppose "64-bit" is an adjective describing something that has 64 bits. I would support moving all the articles to "n-bit architecture", per the lede, which namedrops computer architecture._{ZXCVBNM (TALK)} 06:55, 28 December 2019 (UTC)
• Opppose – fix the other ones instead. Dicklyon (talk) 06:06, 1 January 2020 (UTC)

---

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Backwards compatibility

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)

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)

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

IEC units

@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)

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

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)

APIs

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)