Editing 64-bit computing (section)

== 64-bit data models ==
In 32-bit programs, [[pointer (computer programming)|pointer]]s and data types such as integers generally have the same length. This is not necessarily true on 64-bit machines.<ref>{{cite web |url=http://www.ibm.com/developerworks/power/library/pa-openpower1/#N100C7 |title=Exploring 64-bit development on POWER5: How portable is your code, really? |author=Peter Seebach |website=[[IBM]] |year=2006}}</ref><ref>{{cite web |url=http://www.lysator.liu.se/c/ten-commandments.html |title=The Ten Commandments for C Programmers |author=Henry Spencer}}</ref><ref>{{cite web|url=http://www.datacenterworks.com/stories/thud.html |title=The Story of Thud and Blunder |publisher=Datacenterworks.com |access-date=2010-11-19}}</ref> Mixing data types in programming languages such as [[C (programming language)|C]] and its descendants such as [[C++]] and [[Objective-C]] may thus work on 32-bit implementations but not on 64-bit implementations.

In many programming environments for C and C-derived languages on 64-bit machines, <code>int</code> variables are still 32 bits wide, but long integers and pointers are 64 bits wide. These are described as having an ''LP64'' [[data model]], which is an abbreviation of "Long, Pointer, 64".<ref>{{cite web|url=https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.cbcpx01/datatypesize64.htm|title=ILP32 and LP64 data models and data type sizes|work=z/OS XL C/C++ Programming Guide}}</ref><ref name="why-lp64">{{cite web|url=http://archive.opengroup.org/public/tech/aspen/lp64_wp.htm|title=64-Bit Programming Models|access-date=2020-06-05}}</ref> Other models are the ''ILP64'' data model in which all three data types are 64 bits wide,<ref>{{Cite web|url=https://www.intel.com/content/www/us/en/develop/documentation/mkl-linux-developer-guide/top/linking-your-application-with-the-intel-math-kernel-library/linking-in-detail/linking-with-interface-libraries/using-the-ilp64-interface-vs-lp64-interface.html|title=Using the ILP64 Interface vs. LP64 Interface|website=Intel|access-date=Jun 24, 2020}}</ref><ref name="why-lp64"/> and even the ''SILP64'' model where ''short'' integers are also 64 bits wide.<ref name="SILP64"/><ref name="SIPL64-2"/> However, in most cases the modifications required are relatively minor and straightforward, and many well-written programs can simply be recompiled for the new environment with no changes. Another alternative is the ''LLP64'' model, which maintains compatibility with 32-bit code by leaving both <code>int</code> and <code>long</code> as 32-bit.<ref>{{cite web|url=https://docs.microsoft.com/en-us/windows/desktop/winprog64/abstract-data-models|title=Abstract Data Models - Windows applications|date=May 30, 2018}}</ref><ref name="why-lp64"/> ''LL'' refers to the ''long long integer'' type, which is at least 64 bits on all platforms, including 32-bit environments.

There are also systems with 64-bit processors using an ''ILP32'' data model, with the addition of 64-bit long long integers; this is also used on many platforms with 32-bit processors. This model reduces code size and the size of data structures containing pointers, at the cost of a much smaller address space, a good choice for some embedded systems. For instruction sets such as x86 and ARM in which the 64-bit version of the instruction set has more registers than does the 32-bit version, it provides access to the additional registers without the space penalty. It is common in 64-bit RISC machines,{{citation needed|date=February 2021}} explored in x86 as [[x32 ABI]], and has recently been used in the [[Apple Watch Series 4]] and 5.<ref>{{cite web|url=http://infocenter.arm.com/help/topic/com.arm.doc.dai0490a/index.html|title=ILP32 for AArch64 Whitepaper|publisher=ARM Limited|date=June 9, 2015|access-date=October 9, 2018|archive-url=https://web.archive.org/web/20181230130324/http://infocenter.arm.com/help/topic/com.arm.doc.dai0490a/index.html|archive-date=December 30, 2018|url-status=live}}</ref><ref name="auto">{{cite web|url=https://gist.github.com/woachk/943828f37c14563a607a26116435bf27|title=Apple devices in 2018|publisher=woachk, security researcher|date=October 6, 2018}}</ref>

{| class="wikitable sortable" style="text-align:right;"
|+ 64-bit data models
|- style="line-height:133%"
! Data<br>model
! {{mono|short}}<br/>{{mono|int}}
! {{mono|int}}
! {{mono|long}}<br/>{{mono|int}}
! {{mono|long<br>long}}
! Pointer,<br/>{{mono|size_t}}
! Sample operating systems
|-
! {{rh|align=right}} | ILP32
| 16
| '''32'''
| '''32'''
| 64
| '''32'''
| style="text-align:left;" | x32 and {{Mono|arm64ilp32}} ABIs on Linux systems; MIPS N32 ABI.
|-
! {{rh|align=right}} | LLP64
| 16
| 32
| 32
| '''64'''
| '''64'''
| style="text-align:left;" | [[Microsoft Windows]] (x86-64, IA-64, and ARM64) using [[Visual C++]]; and [[MinGW]]
|-
! {{rh|align=right}} | LP64
| 16
| 32
| '''64'''
| '''64'''
| '''64'''
| style="text-align:left;" | Most [[Unix]] and [[Unix-like]] systems, e.g., [[Solaris (operating system)|Solaris]], [[Linux]], [[BSD]], [[macOS]]. [[Windows]] when using [[Cygwin]]; [[z/OS]]
|-
! {{rh|align=right}} | ILP64
| 16
| '''64'''
| '''64'''
| '''64'''
| '''64'''
| style="text-align:left;" | [[HAL Computer Systems]] port of Solaris to the [[HAL SPARC64|SPARC64]]
|-
! {{rh|align=right}} | SILP64
| '''64'''
| '''64'''
| '''64'''
| '''64'''
| '''64'''
| style="text-align:left;" | ''Classic'' [[UNICOS]]<ref name="SILP64">{{cite web|url=http://docs.cray.com/books/004-2179-001/html-004-2179-001/rvc5mrwh.html#QEARLRWH|title=Cray C/C++ Reference Manual|at=Table 9-1. Cray Research systems data type mapping|date=August 1998|access-date=October 15, 2013|archive-url=https://web.archive.org/web/20131016001801/http://docs.cray.com/books/004-2179-001/html-004-2179-001/rvc5mrwh.html|archive-date=October 16, 2013|url-status=dead}}</ref><ref name="SIPL64-2">{{Cite web|url=https://pubs.cray.com/content/S-2179/8.7/cray-c-and-c++-reference-manual/about-the-cray-and-c++-reference-manual|title=Cray C and C++ Reference Manual (8.7) S-2179|access-date=Jun 24, 2020}}</ref> (versus UNICOS/mp, etc.)
|}

Many 64-bit platforms <!-- not "compilers", because compilers default to emitting code for the targeted platform --> today use an ''LP64'' model (including Solaris, [[AIX]], [[HP-UX]], Linux, macOS, BSD, and IBM z/OS). Microsoft Windows uses an ''LLP64'' model. The disadvantage of the LP64 model is that storing a <code>long</code> into an <code>int</code> truncates. On the other hand, converting a pointer to a <code>long</code> will "work" in LP64. In the LLP64 model, the reverse is true. These are not problems which affect fully standard-compliant code, but code is often written with implicit assumptions about the widths of data types. C code should prefer (<code>u</code>)<code>intptr_t</code> instead of <code>long</code> when casting pointers into integer objects.

A programming model is a choice made to suit a given compiler, and several can coexist on the same OS. However, the programming model chosen as the primary model for the OS [[application programming interface]] (API) typically dominates.

Another consideration is the data model used for [[device driver]]s. Drivers make up the majority of the operating system code in most modern operating systems{{Citation needed|date=May 2011}} (although many may not be loaded when the operating system is running). Many drivers use pointers heavily to manipulate data, and in some cases have to load pointers of a certain size into the hardware they support for [[direct memory access]] (DMA). As an example, a driver for a 32-bit PCI device asking the device to DMA data into upper areas of a 64-bit machine's memory could not satisfy requests from the operating system to load data from the device to memory above the 4 [[gigabyte]] barrier, because the pointers for those addresses would not fit into the DMA registers of the device. This problem is solved by having the OS take the memory restrictions of the device into account when generating requests to drivers for DMA, or by using an [[input–output memory management unit]] (IOMMU).