Processor registers are typically divided into several groups: integer, floating-point, single instruction, multiple data (SIMD), control, and often special registers for address arithmetic which may have various uses and names such as address, index, or base registers. However, in modern designs, these functions are often performed by more general purpose integer registers. In most processors, only integer or address-registers can be used to address data in memory; the other types of registers cannot. The size of these registers therefore normally limits the amount of directly addressable memory, even if there are registers, such as floating-point registers, that are wider.
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. For example, although the x86/x87 architecture has instructions able to load and store 64-bit (and 32-bit) floating-point values in memory, the internal floating-point data and register format is 80 bits wide, while the general-purpose registers are 32 bits wide. In contrast, the 64-bit Alpha family uses a 64-bit floating-point data and register format, and 64-bit integer registers.
Many computer instruction sets are designed so that a single integer register can store the memory address to any location in the computer's physical or virtual memory. Therefore, the total number of addresses to memory is often determined by the width of these registers. The IBM System/360 of the 1960s was an early 32-bit computer; it had 32-bit integer registers, although it only used the low order 24 bits of a word for addresses, resulting in a 16 MiB (16 × 10242 bytes) address space. 32-bit superminicomputers, such as the DEC VAX, became common in the 1970s, and 32-bit microprocessors, such as the Motorola 68000 family and the 32-bit members of the x86 family starting with the Intel 80386, appeared in the mid-1980s, making 32 bits something of a de facto consensus as a convenient register size.
A 32-bit address register meant that 232 addresses, or 4 GB of random-access memory (RAM), could be referenced. When these architectures were devised, 4 GB of memory was so far beyond the typical amounts (4 MiB) in installations, that this was considered to be enough headroom for addressing. 4.29 billion addresses were considered an appropriate size to work with for another important reason: 4.29 billion integers are enough to assign unique references to most entities in applications like databases.
Some supercomputer architectures of the 1970s and 1980s, such as the Cray-1,3 used registers up to 64 bits wide, and supported 64-bit integer arithmetic, although they did not support 64-bit addressing. In the mid-1980s, Intel i8604 development began culminating in a 1989 release; the i860 had 32-bit integer registers and 32-bit addressing, so it was not a fully 64-bit processor, although its graphics unit supported 64-bit integer arithmetic.5 However, 32 bits remained the norm until the early 1990s, when the continual reductions in the cost of memory led to installations with amounts of RAM approaching 4 GB, and the use of virtual memory spaces exceeding the 4 GB ceiling became desirable for handling certain types of problems. In response, MIPS and DEC developed 64-bit microprocessor architectures, initially for high-end workstation and server machines. By the mid-1990s, HAL Computer Systems, Sun Microsystems, IBM, Silicon Graphics, and Hewlett-Packard had developed 64-bit architectures for their workstation and server systems. A notable exception to this trend were mainframes from IBM, which then used 32-bit data and 31-bit address sizes; the IBM mainframes did not include 64-bit processors until 2000. During the 1990s, several low-cost 64-bit microprocessors were used in consumer electronics and embedded applications. Notably, the Nintendo 646 and the PlayStation 2 had 64-bit microprocessors before their introduction in personal computers. High-end printers, network equipment, and industrial computers also used 64-bit microprocessors, such as the Quantum Effect Devices R5000.7 64-bit computing started to trickle down to the personal computer desktop from 2003 onward, when some models in Apple's Macintosh lines switched to PowerPC 970 processors (termed G5 by Apple), and Advanced Micro Devices (AMD) released its first 64-bit x86-64 processor. Physical memory eventually caught up with 32-bit limits. In 2023, laptop computers were commonly equipped with 16GB and servers starting from 64 GB of memory,8 greatly exceeding the 4 GB address capacity of 32 bits.
In principle, a 64-bit microprocessor can address 16 EB (16 × 10246 = 264 = 18,446,744,073,709,551,616 bytes) of memory. However, not all instruction sets, and not all processors implementing those instruction sets, support a full 64-bit virtual or physical address space.
The x86-64 architecture (as of March 2024) allows 48 bits for virtual memory and, for any given processor, up to 52 bits for physical memory.3132 These limits allow memory sizes of 256 TB (256 × 10244 bytes) and 4 PB (4 × 10245 bytes), respectively. A PC cannot currently contain 4 petabytes of memory (due to the physical size of the memory chips), but AMD envisioned large servers, shared memory clusters, and other uses of physical address space that might approach this in the foreseeable future. Thus the 52-bit physical address provides ample room for expansion while not incurring the cost of implementing full 64-bit physical addresses. Similarly, the 48-bit virtual address space was designed to provide 65,536 (216) times the 32-bit limit of 4 GB (4 × 10243 bytes), allowing room for later expansion and incurring no overhead of translating full 64-bit addresses.
The Power ISA v3.0 allows 64 bits for an effective address, mapped to a segmented address with between 65 and 78 bits allowed, for virtual memory, and, for any given processor, up to 60 bits for physical memory.33
The Oracle SPARC Architecture 2015 allows 64 bits for virtual memory and, for any given processor, between 40 and 56 bits for physical memory.34
The ARM AArch64 Virtual Memory System Architecture allows from 48 to 56 bits for virtual memory and, for any given processor, from 32 to 56 bits for physical memory.35
The DEC Alpha specification requires minimum of 43 bits of virtual memory address space (8 TB) to be supported, and hardware need to check and trap if the remaining unsupported bits are zero (to support compatibility on future processors). Alpha 21064 supported 43 bits of virtual memory address space (8 TB) and 34 bits of physical memory address space (16 GB). Alpha 21164 supported 43 bits of virtual memory address space (8 TB) and 40 bits of physical memory address space (1 TB). Alpha 21264 supported user-configurable 43 or 48 bits of virtual memory address space (8 TB or 256 TB) and 44 bits of physical memory address space (16 TB).
A change from a 32-bit to a 64-bit architecture is a fundamental alteration, as most operating systems must be extensively modified to take advantage of the new architecture, because that software has to manage the actual memory addressing hardware.36 Other software must also be ported to use the new abilities; older 32-bit software may be supported either by virtue of the 64-bit instruction set being a superset of the 32-bit instruction set, so that processors that support the 64-bit instruction set can also run code for the 32-bit instruction set, or through software emulation, or by the actual implementation of a 32-bit processor core within the 64-bit processor, as with some Itanium processors from Intel, which included an IA-32 processor core to run 32-bit x86 applications. The operating systems for those 64-bit architectures generally support both 32-bit and 64-bit applications.37
One significant exception to this is the IBM AS/400, software for which is compiled into a virtual instruction set architecture (ISA) called Technology Independent Machine Interface (TIMI); TIMI code is then translated to native machine code by low-level software before being executed. The translation software is all that must be rewritten to move the full OS and all software to a new platform, as when IBM transitioned the native instruction set for AS/400 from the older 32/48-bit IMPI to the newer 64-bit PowerPC-AS, codenamed Amazon. The IMPI instruction set was quite different from even 32-bit PowerPC, so this transition was even bigger than moving a given instruction set from 32 to 64 bits.
On 64-bit hardware with x86-64 architecture (AMD64), most 32-bit operating systems and applications can run with no compatibility issues. While the larger address space of 64-bit architectures makes working with large data sets in applications such as digital video, scientific computing, and large databases easier, there has been considerable debate on whether they or their 32-bit compatibility modes will be faster than comparably priced 32-bit systems for other tasks.
A compiled Java program can run on a 32- or 64-bit Java virtual machine with no modification. The lengths and precision of all the built-in types, such as char, short, int, long, float, and double, and the types that can be used as array indices, are specified by the standard and are not dependent on the underlying architecture. Java programs that run on a 64-bit Java virtual machine have access to a larger address space.38
Speed is not the only factor to consider in comparing 32-bit and 64-bit processors. Applications such as multi-tasking, stress testing, and clustering – for high-performance computing (HPC) – may be more suited to a 64-bit architecture when deployed appropriately. For this reason, 64-bit clusters have been widely deployed in large organizations, such as IBM, HP, and Microsoft.
Summary:
A common misconception is that 64-bit architectures are no better than 32-bit architectures unless the computer has more than 4 GB of random-access memory.39 This is not entirely true:
The main disadvantage of 64-bit architectures is that, relative to 32-bit architectures, the same data occupies more space in memory (due to longer pointers and possibly other types, and alignment padding). This increases the memory requirements of a given process and can have implications for efficient processor cache use. Maintaining a partial 32-bit model is one way to handle this, and is in general reasonably effective. For example, the z/OS operating system takes this approach, requiring program code to reside in 31-bit address spaces (the high order bit is not used in address calculation on the underlying hardware platform) while data objects can optionally reside in 64-bit regions. Not all such applications require a large address space or manipulate 64-bit data items, so these applications do not benefit from these features.
x86-based 64-bit systems sometimes lack equivalents of software that is written for 32-bit architectures. The most severe problem in Microsoft Windows is incompatible device drivers for obsolete hardware. Most 32-bit application software can run on a 64-bit operating system in a compatibility mode, also termed an emulation mode, e.g., Microsoft WoW64 Technology for IA-64 and AMD64. The 64-bit Windows Native Mode42 driver environment runs atop 64-bit NTDLL.DLL, which cannot call 32-bit Win32 subsystem code (often devices whose actual hardware function is emulated in user mode software, like Winprinters). Because 64-bit drivers for most devices were unavailable until early 2007 (Vista x64), using a 64-bit version of Windows was considered a challenge. However, the trend has since moved toward 64-bit computing, more so as memory prices dropped and the use of more than 4 GB of RAM increased. Most manufacturers started to provide both 32-bit and 64-bit drivers for new devices, so unavailability of 64-bit drivers ceased to be a problem. 64-bit drivers were not provided for many older devices, which could consequently not be used in 64-bit systems.
Driver compatibility was less of a problem with open-source drivers, as 32-bit ones could be modified for 64-bit use. Support for hardware made before early 2007, was problematic for open-source platforms, due to the relatively small number of users.
64-bit versions of Windows cannot run 16-bit software. However, most 32-bit applications will work well. 64-bit users are forced to install a virtual machine of a 16- or 32-bit operating system to run 16-bit applications or use one of the alternatives for NTVDM.43
Mac OS X 10.4 "Tiger" and Mac OS X 10.5 "Leopard" had only a 32-bit kernel, but they can run 64-bit user-mode code on 64-bit processors. Mac OS X 10.6 "Snow Leopard" had both 32- and 64-bit kernels, and, on most Macs, used the 32-bit kernel even on 64-bit processors. This allowed those Macs to support 64-bit processes while still supporting 32-bit device drivers; although not 64-bit drivers and performance advantages that can come with them. Mac OS X 10.7 "Lion" ran with a 64-bit kernel on more Macs, and OS X 10.8 "Mountain Lion" and later macOS releases only have a 64-bit kernel. On systems with 64-bit processors, both the 32- and 64-bit macOS kernels can run 32-bit user-mode code, and all versions of macOS up to macOS Mojave (10.14) include 32-bit versions of libraries that 32-bit applications would use, so 32-bit user-mode software for macOS will run on those systems. The 32-bit versions of libraries have been removed by Apple in macOS Catalina (10.15).
Linux and most other Unix-like operating systems, and the C and C++ toolchains for them, have supported 64-bit processors for many years. Many applications and libraries for those platforms are open-source software, written in C and C++, so that if they are 64-bit-safe, they can be compiled into 64-bit versions. This source-based distribution model, with an emphasis on frequent releases, makes availability of application software for those operating systems less of an issue.
In 32-bit programs, pointers and data types such as integers generally have the same length. This is not necessarily true on 64-bit machines.444546 Mixing data types in programming languages such as 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, int 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".4748 Other models are the ILP64 data model in which all three data types are 64 bits wide,4950 and even the SILP64 model where short integers are also 64 bits wide.5152 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 int and long as 32-bit.5354 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, explored in x86 as x32 ABI, and has recently been used in the Apple Watch Series 4 and 5.5556
Many 64-bit platforms 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 long into an int truncates. On the other hand, converting a pointer to a long 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 (u)intptr_t instead of long 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 drivers. Drivers make up the majority of the operating system code in most modern operating systems (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).
As of August 2023, 64-bit architectures for which processors are being manufactured include:
Most architectures of 64 bits that are derived from the same architecture of 32 bits can execute code written for the 32-bit versions natively, with no performance penalty. This kind of support is commonly called bi-arch support or more generally multi-arch support.
such as floating-point numbers. /wiki/Floating-point_arithmetic ↩
Pentium Processor User's Manual Volume 1: Pentium Processor Data Book (PDF). Intel. 1993. https://bitsavers.org/components/intel/pentium/1993_Intel_Pentium_Processor_Users_Manual_Volume_1.pdf ↩
"Cray-1 Computer System Hardware Reference Manual" (PDF). Cray Research. 1977. Retrieved October 8, 2013. https://bitsavers.trailing-edge.com/pdf/cray/CRAY-1/2240004C_CRAY-1_Hardware_Reference_Nov77.pdf ↩
Grimes, Jack; Kohn, Les; Bharadhwaj, Rajeev (July–August 1989). "The Intel i860 64-Bit Processor: A General-Purpose CPU with 3D Graphics Capabilities". IEEE Computer Graphics and Applications. 9 (4): 85–94. doi:10.1109/38.31467. S2CID 38831149. Retrieved 2010-11-19. https://www.computer.org/csdl/mags/cg/1989/04/mcg1989040085-abs.html ↩
"i860 Processor Family Programmer's Reference Manual" (PDF). Intel. 1991. Retrieved September 12, 2019. https://bitsavers.org/components/intel/i860/240875-001_i860_64-Bit_Microprocessor_Programmers_Reference_May91.pdf ↩
"NEC Offers Two High Cost Performance 64-bit RISC Microprocessors" (Press release). NEC. 1998-01-20. Retrieved 2011-01-09. Versions of the VR4300 processor are widely used in consumer and office automation applications, including the popular Nintendo 64™ video game and advanced laser printers such as the recently announced, award-winning Hewlett-Packard LaserJet 4000 printer family. http://www.nec.co.jp/press/en/9801/2002.htm ↩
MIPS R5000 Microprocessor Technical Backgrounder (PDF), MIPS Technologies, Inc, retrieved 2024-08-19 http://www.sgidepot.co.uk/depot/R5000_Pr_Ov.pdf ↩
"DDR5 | DRAM". Samsung Semiconductor Global. Retrieved 2025-01-19. https://semiconductor.samsung.com/dram/ddr/ddr5/ ↩
"i860 64-Bit Microprocessor". Intel. 1989. Archived from the original on 19 March 2011. Retrieved 30 November 2010. https://web.archive.org/web/20110319200648/https://smithsonianchips.si.edu/intel/i860.htm ↩
"Atari Jaguar History". AtariAge. https://www.atariage.com/Jaguar/history.html ↩
Joe Heinrich (1994). MIPS R4000 Microprocessor User's Manual (2nd ed.). MIPS Technologies, Inc. ↩
Richard L. Sites (1992). "Alpha AXP Architecture". Digital Technical Journal. 4 (4). Digital Equipment Corporation. ↩
Gwennap, Linley (3 October 1994). "UltraSparc Unleashes SPARC Performance". Microprocessor Report. 8 (13). MicroDesign Resources. ↩
Bishop, J. W.; et al. (July 1996). "PowerPC AS A10 64-bit RISC microprocessor". IBM Journal of Research and Development. 40 (4). IBM Corporation: 495–505. doi:10.1147/rd.404.0495. /wiki/Doi_(identifier) ↩
Gwennap, Linley (14 November 1994). "PA-8000 Combines Complexity and Speed". Microprocessor Report. 8 (15). MicroDesign Resources. ↩
F. P. O'Connell; S. W. White (November 2000). "POWER3: The next generation of PowerPC processors". IBM Journal of Research and Development. 44 (6). IBM Corporation: 873–884. doi:10.1147/rd.446.0873. /wiki/Doi_(identifier) ↩
"VIA Unveils Details of Next-Generation Isaiah Processor Core" (Press release). VIA Technologies, Inc. Archived from the original on 2007-10-11. Retrieved 2007-07-18. https://web.archive.org/web/20071011053054/https://via.com.tw/en/resources/pressroom/2004_archive/pr041005_fpf-isaiah.jsp ↩
"ARMv8 Technology Preview" (PDF). October 31, 2011. Archived from the original (PDF) on November 11, 2011. Retrieved November 15, 2012. https://web.archive.org/web/20111111161327/https://www.arm.com/files/downloads/ARMv8_Architecture.pdf ↩
"ARM Launches Cortex-A50 Series, the World's Most Energy-Efficient 64-bit Processors" (Press release). ARM Holdings. Retrieved 2012-10-31. https://www.arm.com/about/newsroom/arm-launches-cortex-a50-series-the-worlds-most-energy-efficient-64-bit-processors.php ↩
"ARM Keynote: ARM Cortex-A53 and ARM Cortex-A57 64bit ARMv8 processors launched". ARMdevices.net. 2012-10-31. http://armdevices.net/2012/10/31/arm-keynote-arm-cortex-a53-and-arm-cortex-a57-64bit-armv8-processors-launched/ ↩
Asanović, Krste; Patterson, David A. (August 6, 2014). Instruction Sets Should Be Free: The Case For RISC-V (PDF). EECS Department, University of California, Berkeley. UCB/EECS-2014-146. /wiki/Krste_Asanovi%C4%87 ↩
"Synopsys Introduces New 64-bit ARC Processor IP". Archived from the original on 31 March 2022. https://news.synopsys.com/2020-04-07-Synopsys-Introduces-New-64-bit-ARC-Processor-IP-Delivering-Up-to-3x-Performance-Increase-for-High-End-Embedded-Applications ↩
Stefan Berka. "Unicos Operating System". www.operating-system.org. Archived from the original on 26 November 2010. Retrieved 2010-11-19. http://www.operating-system.org/betriebssystem/_english/bs-unicos.htm ↩
Jon "maddog" Hall (Jun 1, 2000). "My Life and Free Software". Linux Journal. /wiki/Jon_Hall_(programmer) ↩
Andi Kleen. Porting Linux to x86-64 (PDF). Ottawa Linux Symposium 2001. Status: The kernel, compiler, tool chain work. The kernel boots and work on simulator and is used for porting of userland and running programs https://www.kernel.org/doc/ols/2001/x86-64.pdf ↩
John Siracusa (September 2009). "Mac OS X 10.6 Snow Leopard: the Ars Technica review". Ars Technica. p. 5. Archived from the original on 9 October 2009. Retrieved 2009-09-06. https://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/5 ↩
Joris Evers (5 January 2005). "Microsoft nixes Windows XP for Itanium". Computerworld. Archived from the original on 18 June 2013. Retrieved 17 October 2017. https://web.archive.org/web/20130618025711/http://www.computerworld.com/s/article/98716/Microsoft_nixes_Windows_XP_for_Itanium?taxonomyId=125 ↩
"Microsoft Raises the Speed Limit with the Availability of 64-Bit Editions of Windows Server 2003 and Windows XP Professional" (Press release). Microsoft. April 25, 2005. Retrieved September 10, 2015. https://news.microsoft.com/2005/04/25/microsoft-raises-the-speed-limit-with-the-availability-of-64-bit-editions-of-windows-server-2003-and-windows-xp-professional/ ↩
"UEFI on Dell BizClient Platforms" (PDF). https://uefi.org/sites/default/files/resources/UEFI_on_Dell%20BizClient_Platforms.pdf ↩
"AMD64 Programmer's Manual Volume 2: System Programming" (PDF). Advanced Micro Devices. March 2024. p. 127. https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24593.pdf ↩
"Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3A: System Programming Guide, Part 1" (PDF). Intel. September 2016. p. 4-2. https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf ↩
"Power ISA Version 3.0". IBM. November 30, 2015. p. 983. https://openpowerfoundation.org/?resource_lib=power-isa-version-3-0 ↩
"Oracle SPARC Architecture 2015 Draft D1.0.9" (PDF). Oracle. November 16, 2016. p. 475. Archived from the original (PDF) on April 22, 2020. https://web.archive.org/web/20200422022137/https://community.oracle.com/servlet/JiveServlet/downloadBody/1005258-102-3-148654/OracleSparcArchitecture2015.pdf ↩
"ARM Architecture Reference Manual for A-profile architecture". 30 November 2024. section D8.1.6 "Implemented physical address size", section D8.1.8 "Supported virtual address ranges". https://developer.arm.com/documentation/ddi0487/latest ↩
Mashey, John (October 2006). "The Long Road to 64 Bits". ACM Queue. 4 (8): 85–94. doi:10.1145/1165754.1165766. https://doi.org/10.1145%2F1165754.1165766 ↩
"Windows 7: 64 bit vs 32 bit?". W7 Forums. 2 April 2009. Archived from the original on 5 April 2009. Retrieved 2009-04-05. https://www.w7forums.com/threads/windows-7-64-bit-vs-32-bit.484/ ↩
"Frequently Asked Questions About the Java HotSpot VM". Oracle. Retrieved 2024-12-13. https://www.oracle.com/java/technologies/hotspotfaq.html ↩
"A description of the differences between 32-bit versions of Windows Vista and 64-bit versions of Windows Vista". Archived from the original on 2011-10-15. Retrieved 2011-10-14. https://web.archive.org/web/20111015085813/https://support.microsoft.com/kb/946765 ↩
Mark Russinovich (2008-07-21). "Pushing the Limits of Windows: Physical Memory". Archived from the original on 2017-04-07. Retrieved 2017-03-09. https://web.archive.org/web/20170407050448/https://blogs.technet.microsoft.com/markrussinovich/2008/07/21/pushing-the-limits-of-windows-physical-memory/ ↩
Chappell, Geoff (2009-01-27). "Licensed Memory in 32-Bit Windows Vista". geoffchappell.com. WP:SPS. Retrieved 9 March 2017. http://www.geoffchappell.com/notes/windows/license/memory.htm ↩
"Inside Native Applications". Technet.microsoft.com. 2006-11-01. Archived from the original on 23 October 2010. Retrieved 2010-11-19. https://technet.microsoft.com/en-us/sysinternals/bb897447.aspx ↩
Lincoln Spector (August 12, 2013). "Run an old program on a new PC". https://www.pcworld.com/article/2045345/run-an-old-program-on-a-new-pc.html ↩
Peter Seebach (2006). "Exploring 64-bit development on POWER5: How portable is your code, really?". IBM. http://www.ibm.com/developerworks/power/library/pa-openpower1/#N100C7 ↩
Henry Spencer. "The Ten Commandments for C Programmers". http://www.lysator.liu.se/c/ten-commandments.html ↩
"The Story of Thud and Blunder". Datacenterworks.com. Retrieved 2010-11-19. http://www.datacenterworks.com/stories/thud.html ↩
"ILP32 and LP64 data models and data type sizes". z/OS XL C/C++ Programming Guide. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.cbcpx01/datatypesize64.htm ↩
"64-Bit Programming Models". Retrieved 2020-06-05. http://archive.opengroup.org/public/tech/aspen/lp64_wp.htm ↩
"Using the ILP64 Interface vs. LP64 Interface". Intel. Retrieved Jun 24, 2020. 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 ↩
"Cray C/C++ Reference Manual". August 1998. Table 9-1. Cray Research systems data type mapping. Archived from the original on October 16, 2013. Retrieved October 15, 2013. https://web.archive.org/web/20131016001801/http://docs.cray.com/books/004-2179-001/html-004-2179-001/rvc5mrwh.html ↩
"Cray C and C++ Reference Manual (8.7) S-2179". Retrieved Jun 24, 2020. https://pubs.cray.com/content/S-2179/8.7/cray-c-and-c++-reference-manual/about-the-cray-and-c++-reference-manual ↩
"Abstract Data Models - Windows applications". May 30, 2018. https://docs.microsoft.com/en-us/windows/desktop/winprog64/abstract-data-models ↩
"ILP32 for AArch64 Whitepaper". ARM Limited. June 9, 2015. Archived from the original on December 30, 2018. Retrieved October 9, 2018. http://infocenter.arm.com/help/topic/com.arm.doc.dai0490a/index.html ↩
"Apple devices in 2018". woachk, security researcher. October 6, 2018. https://gist.github.com/woachk/943828f37c14563a607a26116435bf27 ↩