64位元

架构影响

处理器中的寄存器通常可分为三种：整数、浮点数、其它。在所有常见的主流处理器中，只有整数寄存器（integer register）才可存放指针值（存储器数据的地址）。非整数寄存器不能存放指针来读写存储器，因此不能用来避开任何受到整数寄存器大小所影响的存储器限制。
几乎所有常见的主流处理器（大部分的ARM和32位MIPS实现是明显的例外）集成了浮点数硬件，它有可能使用64位寄存器保存数据，以供处理。例如，x86架构包含了x87浮点数指令，并使用8个80位寄存器构成堆栈结构。后来的x86修改版和x86-64架构，又加入SSE指令，它使用8个128位宽的寄存器（在x86-64中有16个寄存器）。与之相较，64位Alpha系列处理器，除了32个64位宽整数寄存器以外，也定义了32个64位宽的浮点数寄存器。

存储器限制

然而在1990年初，成本不断降低的存储器，使安装的存储器数量逼近4 GB，且在处理某些类型的问题时，可以想像虚拟内存的使用空间将超过4 GB上限。为此，一些公司开始发布新的64位架构芯片家族，最初是提供给超级计算机、顶级工作站和服务器机器。64位运算逐渐流向个人计算机，在2003年，某些型号的苹果公司Macintosh产生线转向PowerPC 970处理器（苹果公司称为“G5”），并在2006年，转向EM64T处理器，且x86-64处理器在顶级的PC中遂渐普及。64位架构的出现，有效的将存储器上限提升至2⁶⁴地址，相当于1844多京或16 EB的存储器。从这个角度来看，在4 MB主存很普遍时，最大的存储器上限2³²的地址大约是一般安装存储器的1000倍。如今，当1 GB的主存很普遍时，2⁶⁴的地址上限大约是1百亿倍。
今天市面上大部分的消费级PC存在着人为的存储器限制，因受限于实体上的限制，而几乎不太可能需要完整支持16 EB容量。举例来说，Apple的Mac Pro最多可安装物理内存至128 GB，而无必要支持超过的大小。最新的Linux核心（版本3.11.2）可编译成最高支持64 GB的存储器。

32与64位

从32位到64位架构的改变是一个根本的改变，因为大多数操作系统必须进行全面性修改，以获取新架构的优点。其它软件也必须进行移植，以使用新的性能；较旧的软件一般可借由硬件兼容模式（新的处理器支持较旧的32位版本指令集）或软件模拟进行支持。或者直接在64位处理器里面实现32位处理器核心（如同Intel的Itanium处理器，其内含有x86处理器核心，用来运行32位x86应用程序）。支持64位架构的操作系统，一般同时支持32位和64位的应用程序。
明显的例外是AS/400，其软件运行在虚拟的指令集架构，称为TIMI（技术独立机器界面），它会在运行之前，以低级软件转换成原生机器代码。低级软件必须全部重写，以搬移整个OS以及所有的软件到新的平台。例如，当IBM转移较旧的32/48位“IMPI”指令集到64位PowerPC（IMPI完全不像32位PowerPC，所以这比从32位版本的指令集转移到相同指令集的64位版本的规模还要庞大）。
64位架构无疑可应用在需要处理大量数据的应用程序，如数字视频、科学运算、和早期的大型数据库。在其它工作方面，其32位兼容模式是否会快过同等级的32位系统，这部分已有很多争论。在x86-64架构（AMD64和Intel 64）中，主要的32位操作系统和应用程序，可平滑的运行于64位硬件上。
Sun的64位Java虚拟机的引导速度比32位虚拟机还慢，因为Sun仍假定所有的64位机器都是服务器，而且只有为64位平台实现“服务器”编译器（C2）。“客户端”编译器（C1）产生较慢的代码，不过编译较快速。所以尽管在64位JVM的Java程序在一段很长的周期会运行的较好（一般为长时间运作的“服务器”应用程序），它的引导时间可能更久。对于短生命期的应用程序（如Java编译器javac）增加引导时间可控制运行时间，使64位的JVM整体变慢。
应当指出，在比较32位和64位处理器时，速度并不是唯一的考量因素。应用程序，如多任务、应力测试（stress testing）、集群（clustering，用于HPC）可能更适合64位架构以正确部署。为了以上原因，64位集群已广泛部署于大型组织，如IBM、Vodafone、HP、微软。

软件的可用性

64位系统往往缺乏对应的软件，多数软件均按32位架构编写。最严重的问题是不兼容的驱动程序。尽管32位兼容模式（又称作模拟模式，即微软WoW64技术）可执行大部分软件，但通常无法运行驱动程序（或类似软件），因为驱动程序通常在操作系统和硬件之间运行，无法使用直接模拟。许多开放源始码软件数据包可简单的从源始码编译为可执行于64位环境操作系统，如Linux。所需的条件是供给64位机器的编译器（通常是gcc）。
因为设备的驱动程序通常运行于操作系统核心（Kernel）的内部，有可能以32位行程运行核心，同时支持64位的用户行程。以在核心里的额外消耗为代价，如此可为用户提供受益于64位的存储器和性能，且不破坏现存32位驱动程序的二进制兼容性。这个机制源于OS X激活64位行程，同时支持32位的驱动程序。
大多数32位软件都在新的64位操作系统上运行，但是杀毒软件会有兼容性问题。

64位数据模型

以高级语言编写的应用软件，从32位架构转换到64位架构的各种困难。一个共同的问题是，部分程序员假定指针如同其它数据类型一样有相同的长度。程序员假定他们可以在数据类型之间发送数量而不丢失信息。这些假定只在一部分32位机器上如此（甚至是一部分16位机器），不过在64位机器上就不再如此。C语言及其后代C++尤其容易产生这种错误 。
要在C和C++中避免这种错误，如果确定原始类型的大小为所需的基础，sizeof运算符可用来确定原始类型的大小，无论是在编译以及运行时期。此外，在C99标准中的<limits.h>表头，以及在C++标准中的<limits>表头的numeric_limits类别，可提供更多有用的信息；sizeof只返回字符大小。这个用法使人产生误解，因为一个字符（CHAR_BITS）的大小是由自身决定，在所有的C或C++实现中并未以相同方式定义。然而，除了这些编译器目标DSP以外，“64位 = 8字符（每一字符有8位）”已成标准。
必须谨慎使用ptrdiff_t类型（在标准表头<stddef.h>中）两个指针相减的结果；太多代码宁可不正确的使用“int”或“long”。表示一个指针（而不是指针差异）为一个整数，在此可以使用uintptr_t（它只定义在C99中，不过某些编译器另外集成较早版本的标准以提供之，作为一个扩展）。
C和C++并未定义指针、整数型（int）、长型（long）为特定的比特数目。
在主要的32位机器程序设计环境中，指针、“int”变量、“long”变量全部都是32位长。
然而，在64位机器下的许多程序设计环境，“int”变量仍然是32位宽，不过“long”和指针是64位宽，上述内容称为LP64 数据模型。另一个选择是ILP64数据模型，三种数据类型都是64位宽，甚至SILP64连“short”变量也是64位宽。然而，大多数情况下所需的修改是相对次要且简单，而且许多编写良好的程序可以简单的重新编译给新的环境，而无须修改。另一个选择是LLP64模型，其维持32位代码的兼容性，使int和long为32位。“LL”指“long long”类型，其在所有平台下至少是64位，包括32位环境。
今天有许多64位编译器使用LP64模型（包括Solaris、AIX、HP、Linux、Mac OS X、IBM z/OS原生编译器）。微软的VC++编译器使用LLP64模型。其缺点是在LP64模型中将long存放到int可能会溢出。另一方面，还会使强制转型一个指针为long可以作用；在LLP模型下，情况则刚好相反。两者皆不应该出现在合乎C99的代码中。
注意，程序设计模型是在预编译器底层选择的，且数个模型可共存于同一操作系统。然而一般由OS API选择程序设计模型作为原始模型。
另一个考量是用于驱动程序的数据模式。在现代的操作系统中，驱动程序弥补了大多数的操作系统代码（尽管许多代码可能不会加载，当操作系统运行时）。许多驱动程序大量使用指针操控数据，且在某些情况下必须读入一定大小的指针进入支持DMA的硬件。举个例子，提供给32位PCI设备的驱动程序，请求设备的DMA数据进入64位机器存储器的较高区域，可能无法满足来自操作系统从设备到大于4 GB存储器读入数据的要求。因为对于这些地址的指针，将不适合设备的DMA寄存器。这个问题可如下解决，当向设备发出DMA请求时，OS采用与设备相符的存储器限制，或者使用IOMMU。

超越64位

直至2007年，64位字组似乎已满足大部分的运用。不过仍应提到，IBM的System/370及后继者使用128位浮点数，且许多现代处理器也内含128位浮点数寄存器。System/370及后继者尤其显著，在这方面，他们也使用多达16位组的可变长度十进制数（即128位）。

影像

在数字图像中，64位为附有16位Alpha通道的48位影像。