64位CPU是指CPU内部的通用寄存器的宽度为64比特，支持整数的64比特宽度的算术与逻辑运算。早在1960年代，64位架构便已存在于当时的超级电脑，且早在1990年代，就有以RISC为基础的工作站和服务器。2003年才以x86-64和64位PowerPC处理器架构的形式引入到（在此之前是32位）个人电脑领域的主流。
一个CPU，联系外部的数据总线与地址总线，可能有不同的宽度；术语“64位”也常用于描述这些总线的大小。例如，目前有许多机器有着使用64位总线的32位处理器（如最初的Pentium和之后的CPU，但Intel的32位CPU的地址总线宽度最大为36位），因此有时会被称作“64位”。同样的，某些16位处理器（如MC68000）指的是16/32位处理器具有16位的总线，不过内部也有一些32位的性能。这一术语也可能指电脑指令集的指令长度，或其它的数据项（如常见的64位双精度浮点数）。去掉进一步的条件，“64位”计算机体系结构一般具有64位宽的整数型寄存器，它可支持（内部和外部两者）64位“区块”（chunk）的整数型数据。
处理器中的寄存器通常可分为三种：整数、浮点数、其它。在所有常见的主流处理器中，只有整数寄存器（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位宽的浮点数寄存器。
目前大部分的CPU（截至2005年），其单个寄存器可存放虚拟内存中任意数据的存储器地址（本机）。因此，虚拟内存（电脑在程序的工作区域中所能保留的数据总量）中可用的地址取决于寄存器的宽度。自1960年的IBM System/360起，然后1970年的 DEC VAX微型电脑，以及1980年中期的Intel 80386，在事实上一致开发合用的32位大小的寄存器。32位寄存器意味着232的地址，或可使用4 GB的存储器。当时在设计这些架构时，4 GB的存储器远远超过一般所安装的可用量，而认为已足够用于定址。认为4 GB地址为合适的大小，还有其它重要的理由：在应用程序中，如数据库，42亿多的整数已足够对大部分可计算的实体分配唯一的参考引用。
然而在1990年初，成本不断降低的存储器，使安装的存储器数量逼近4 GB，且在处理某些类型的问题时，可以想像虚拟内存的使用空间将超过4 GB上限。为此，一些公司开始发布新的64位架构芯片家族，最初是提供给超级电脑、顶级工作站和服务器机器。64位运算逐渐流向个人电脑，在2003年，某些型号的苹果公司Macintosh产生线转向PowerPC 970处理器（苹果公司称为“G5”），并在2006年，转向EM64T处理器，且x86-64处理器在顶级的PC中遂渐普及。64位架构的出现，有效的将存储器上限提升至264地址，相当于1844多京或16 EB的存储器。从这个角度来看，在4 MB主存很普遍时，最大的存储器上限232的地址大约是一般安装存储器的1000倍。如今，当1 GB的主存很普遍时，264的地址上限大约是1百亿倍。
今天市面上大部分的消费级PC存在着人为的存储器限制，因受限于实体上的限制，而几乎不太可能需要完整支持16 EB容量。举例来说，Apple的Mac Pro最多可安装物理内存至128 GB，而无必要支持超过的大小。最新的Linux核心（版本3.11.2）可编译成最高支持64 GB的存储器。
从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、微软。
一个常见的误解是：除非电脑安装的存储器大于4GB，否则64位架构不会比32位架构好。这不完全正确：
64位架构主要的缺点是，相对于32位架构，占用相同的数据会消秏更多的存储器空间（由于肿涨的指针，以及其它类型和对齐补白等可能）。这会增加行程对存储器的需求，且可能会影响高性能处理器缓存的使用。解决方法之一是维持一部分32位模型，且大致合理有效。高性能导向的z/OS操作系统便采取这个方法，要求程序代码存放在32位地址空间的任一数字，数据对象则可（选择性）存放在64位区域。
目前主要的商业软件是创建在32位代码，而非64位代码，所以不能获取在64位处理器上较大的64位地址空间，或较宽的64位寄存器和数据路径的优点。然而，免费或自由软件操作系统的用户已经可以使用专有的64位运算环境。并非所有的应用程序都需要大量的地址空间或操作64位数据项，所以这些程序不会享受到较大的地址空间或较宽的寄存器和数据路径的好处；主要受益于64位版本的应用程序，并不会享受到使用x86的版本，会有更多的寄存器可以使用。
64位系统往往缺乏对应的软件，多数软件均按32位架构编写。最严重的问题是不兼容的驱动程序。尽管32位兼容模式（又称作模拟模式，即微软WoW64技术）可执行大部分软件，但通常无法运行驱动程序（或类似软件），因为驱动程序通常在操作系统和硬件之间运行，无法使用直接模拟。许多开放源始码软件数据包可简单的从源始码编译为可执行于64位环境操作系统，如Linux。所需的条件是供给64位机器的编译器（通常是gcc）。
因为设备的驱动程序通常运行于操作系统核心（Kernel）的内部，有可能以32位行程运行核心，同时支持64位的用户行程。以在核心里的额外消耗为代价，如此可为用户提供受益于64位的存储器和性能，且不破坏现存32位驱动程序的二进制兼容性。这个机制源于OS X激活64位行程，同时支持32位的驱动程序。
大多数32位软件都在新的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位的微处理器架构（2006年）有：
大部分64位处理器架构可原生运行32位版本架构的代码，而无任何性能损失。这种支持通常称为双架构支持或更普遍的多架构支持。
直至2007年，64位字组似乎已满足大部分的运用。不过仍应提到，IBM的System/370及后继者使用128位浮点数，且许多现代处理器也内含128位浮点数寄存器。System/370及后继者尤其显著，在这方面，他们也使用多达16位组的可变长度十进制数（即128位）。
在数字图像中，64位为附有16位Alpha通道的48位影像。
本条目部分或全部内容出自以GFDL授权发布的《自由在线电脑词典》（FOLDOC）。
