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位元影像。