64位元
64位元CPU是指CPU内部的通用暫存器的宽度为64位元，支持整数的64-{zh-hans:比特; zh-hant:位元}-宽度的算术与逻辑运算。早在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位元寬的浮點數暫存器。
64位元最大的记忆体上限是16EB，即16,777,216GB、1,6777TB。
記憶體的大小的算法是“2的XX次方”，例如16位元位的內存上限是“2的16次方”即65,536=64KB，而32位元為“2的32次方”即4,294,967,296=4GB，以此類推而64位元就是“2的64次方”即16,777,216GB=1,677TB=16EB。目前人類的在家用電腦中的最高內存上限远低于这个水平，故在實際運用中，64位元的上限可暫時視為無限。
目前大部分的CPU（截至2005年），其單個暫存器可存放虛擬記憶體中任意資料的記憶體位址（本機）。因此，虛擬記憶體（電腦在程式的工作區域中所能保留的資料總量）中可用的位址取決於暫存器的寬度。自1960年的IBM System/360起，然後1970年的 DEC VAX微型電腦，以及1980年中期的Intel 80386，在事實上一致開發合用的32位元大小的暫存器。32位元暫存器意味著2的位址，或可使用4 GB的記憶體。當時在設計這些架構時，4GB的記憶體遠遠超過一般所安裝的可用量，而認為已足夠用於定址。認為4GB位址為合適的大小，還有其它重要的理由：在應用程式中，如資料庫，42億多的整數已足夠對大部分可計算的實體分配唯一的參考引用。
然而在1990年初，成本不斷降低的記憶體，使安裝的記憶體數量逼近4GB，且在處理某些類型的問題時，可以想像虛擬記憶體的使用空間將超過4GB上限。而64位元系统的记忆体上限非常高，因此一些公司開始釋出新的64位元架構晶片家族，最初是提供給超級電腦、頂級工作站和伺服器機器。64位元運算逐漸流向個人電腦，在2003年，某些型號的苹果公司Macintosh產生線轉向PowerPC 970處理器（苹果公司稱為「G5」），並在2006年，轉向EM64T處理器，且x86-64處理器在頂級的PC中遂漸普及。64位元架構的出現，有效的將記憶體上限提升至2位址，相當於1844多京或16 EB的記憶體。從這個角度來看，在4 MB主記憶體很普遍時，最大的記憶體上限2的位址大約是一般安裝記憶體的1000倍。如今，當1GB的主記憶體很普遍時，2的位址上限大約是1百億倍。
今天市面上大部分的消費級PC存在著人為的記憶體限制，因受限於實體上的限制，而幾乎不太可能需要用到16EB的容量。舉例來說，Apple的Mac Pro最多可安裝實體記憶體至128GB，而無必要支援超過的大小。最新的Linux核心（版本3.11.2）可編譯成最高支援64GB的記憶體。
從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++中避免這種錯誤，如果確定原始類型的大小為所需的基礎，codice_1運算子可用來確定原始類型的大小，無論是在編譯以及執行時期。此外，在C99標準中的表頭，以及在C++標準中的表頭的numeric_limits類別，可提供更多有用的資訊；sizeof只返回字元大小。這個用法使人產生誤解，因為一個字元（codice_2）的大小是由自身決定，在所有的C或C++實作中並未以相同方式定義。然而，除了這些編譯器目標DSP以外，「64位元 = 8字元（每一字元有8位元）」已成標準。
必須謹慎使用codice_3型態（在標準表頭codice_4中）兩個指標相減的結果；太多代碼寧可不正確的使用「int」或「long」。表示一個指標（而不是指標差異）為一個整數，在此可以使用codice_5（它只定義在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位元影像。