64비트 컴퓨팅

64비트 Portable Executable 파일의 섹션 테이블에 대한 Hex dump. 64비트 워드는 16개의 16진수 숫자로 표현할 수 있다.

컴퓨터 구조에서 64비트 정수, 메모리 주소, 또는 기타 데이터 단위는 64 비트 폭을 가지는 것을 의미한다. 또한, 64비트 중앙 처리 장치(CPU)와 산술 논리 장치(ALU)는 해당 크기의 프로세서 레지스터, 주소 버스, 또는 데이터 버스를 기반으로 하는 장치를 말한다. 이러한 프로세서를 사용하는 컴퓨터를 64비트 컴퓨터라고 한다.

소프트웨어 관점에서 64비트 컴퓨팅은 64비트 가상 메모리 주소를 사용하는 기계어를 사용하는 것을 의미한다. 하지만 모든 64비트 명령어 집합이 전체 64비트 가상 메모리 주소를 지원하는 것은 아니다. 예를 들어 X86-64와 AArch64는 48비트의 가상 주소만을 지원하며, 나머지 16비트 가상 주소는 모두 0(000...)이거나 모두 1(111...)이어야 한다. 또한 여러 64비트 명령어 집합은 64비트 미만의 물리적 메모리 주소를 지원한다.

'64비트'라는 용어는 64비트 프로세서가 표준인 컴퓨터 세대를 지칭하기도 한다. 64비트는 컴퓨터 구조, 버스, 메모리, CPU, 그리고 이를 기반으로 실행되는 소프트웨어의 특정 등급을 정의하는 워드 크기이다. 64비트 CPU는 1970년대부터 슈퍼컴퓨터(Cray-1, 1975년)에 사용되었으며, 1990년대 초부터는 축소 명령어 집합 컴퓨터(RISC) 기반의 워크스테이션과 서버에서 사용되었다. 2003년에는 X86-64 프로세서와 파워PC G5 형태로 주류 PC 시장에 64비트 CPU가 도입되었다.

64비트 레지스터는 264개(18경 개 이상, 즉 1.8×1019개 이상)의 서로 다른 값을 보유할 수 있다. 64비트로 저장할 수 있는 정수 값의 범위는 사용되는 정수 표현 방식에 따라 달라진다. 가장 흔한 두 가지 표현 방식의 경우, 범위는 (unsigned) 이진수 표현 시 0부터 18,446,744,073,709,551,615(264 − 1)까지이며, 2의 보수 표현 시 −9,223,372,036,854,775,808(−263)부터 9,223,372,036,854,775,807(263 − 1)까지이다. 따라서 64비트 메모리 주소를 가진 프로세서는 264 바이트(16 엑사바이트 또는 EB)의 바이트 주소 지정 가능 메모리에 직접 접근할 수 있다.

별도의 수식어가 없는 한, 64비트 컴퓨터 구조는 일반적으로 64비트 폭의 정수 및 주소 지정용 프로세서 레지스터를 갖추고 있어 64비트 데이터 형식과 주소를 직접 지원한다. 하지만 CPU의 외부 데이터 버스나 주소 버스는 레지스터와 다른 크기(예를 들어, 32비트 펜티엄은 64비트 데이터 버스를 가짐)를 가질 수 있다.

구조적 영향

프로세서 레지스터는 일반적으로 정수, 부동 소수점, SIMD, 제어 레지스터, 그리고 주소, 인덱스, 베이스 레지스터 등 다양한 용도와 이름으로 불리는 주소 연산용 특수 레지스터 등으로 나뉜다. 그러나 현대적 설계에서는 이러한 기능을 더 범용적인 정수 레지스터가 수행하는 경우가 많다. 대부분의 프로세서에서 정수 레지스터나 주소 레지스터만이 메모리의 데이터 주소를 지정하는 데 사용될 수 있으며, 다른 유형의 레지스터는 사용할 수 없다. 따라서 부동 소수점 레지스터처럼 더 넓은 레지스터가 존재하더라도, 이러한 레지스터들의 크기가 직접 주소 지정이 가능한 메모리 양을 제한하게 된다.

대부분의 고성능 32비트 및 64비트 프로세서(일부 구형 또는 임베디드 ARM 아키텍처 및 32비트 MIPS 아키텍처 CPU는 예외)는 통합 부동 소수점 하드웨어를 갖추고 있으며, 이는 대개 64비트 데이터 단위를 기반으로 한다. 예를 들어, X86/X87 아키텍처는 메모리에서 64비트(및 32비트) 부동 소수점 값을 로드하고 저장할 수 있는 명령어를 가지고 있지만, 내부 부동 소수점 데이터 및 레지스터 형식은 80비트인 반면 범용 레지스터는 32비트이다. 이와 대조적으로 64비트 알파 계열은 64비트 부동 소수점 데이터 및 레지스터 형식과 64비트 정수 레지스터를 사용한다.

역사

많은 컴퓨터 명령어 집합은 단일 정수 레지스터가 컴퓨터의 물리적 또는 가상 메모리 내의 임의 위치에 대한 메모리 주소를 저장할 수 있도록 설계되었다. 따라서 메모리의 총 주소 개수는 종종 이 레지스터들의 폭에 의해 결정된다. 1960년대의 IBM 시스템/360은 초기 32비트 컴퓨터였으며, 32비트 정수 레지스터를 갖추고 있었으나 주소 지정에는 워드의 하위 24비트만을 사용하여 16 MiB(16 × 10242 바이트)의 주소 공간을 가졌다. 1970년대에는 DEC VAX와 같은 32비트 미니슈퍼컴퓨터가 보편화되었고, 1980년대 중반에는 모토로라 68000 시리즈와 인텔 80386부터 시작하는 X86 계열의 32비트 프로세서들이 등장하면서 32비트가 편리한 레지스터 크기로 사실상의 표준이 되었다.

32비트 주소 레지스터는 232개의 주소, 즉 4 GB의 랜덤 액세스 메모리(RAM)를 참조할 수 있음을 의미했다. 이러한 아키텍처가 설계될 당시 4GB의 메모리는 설치 환경의 일반적인 양(4 MiB)을 훨씬 뛰어넘는 수치였기에 충분한 여유 공간으로 간주되었다. 42억 9천만 개의 주소는 또 다른 중요한 이유로 적절한 크기로 여겨졌는데, 이는 데이터베이스와 같은 애플리케이션의 대부분의 개체에 고유한 참조를 할당하기에 충분한 정수 개수였기 때문이다.

대부분의 현대 컴퓨터는 랜덤 액세스 메모리 내부에 80억~320억 개의 고유 주소를 담을 수 있는 공간을 포함하고 있으며, 64비트 아키텍처는 20억 배 더 높은 주소에 접근할 수 있다. 전체 64비트 공간이 전부 사용될 일은 없을 것으로 보인다.

크레이-1과 같은 1970년대 및 1980년대의 일부 슈퍼컴퓨터 아키텍처들은 최대 64비트 폭의 레지스터를 사용하고 64비트 정수 연산을 지원했지만, 64비트 주소 지정은 지원하지 않았다. 1980년대 중반에는 인텔 i860 개발이 시작되어 1989년에 출시되었다. i860은 32비트 정수 레지스터와 32비트 주소 지정을 가졌기에 완전한 64비트 프로세서는 아니었으나, 그래픽 유닛이 64비트 정수 연산을 지원했다. 그러나 메모리 가격의 지속적인 하락으로 RAM 용량이 4GB에 근접하고, 4GB 제한을 넘는 가상 메모리 공간의 사용이 특정 유형의 문제를 해결하는 데 바람직해진 1990년대 초까지 32비트가 표준으로 남았다. 이에 대응하여 MIPS와 DEC는 초기에 고성능 워크스테이션 및 서버용으로 64비트 마이크로프로세서 아키텍처를 개발했다. 1990년대 중반까지 HAL 컴퓨터 시스템즈, 썬 마이크로시스템즈, IBM, 실리콘 그래픽스, 휴렛 팩커드는 워크스테이션 및 서버 시스템용 64비트 아키텍처를 개발했다. 이 추세의 예외적인 사례로 당시 32비트 데이터와 31비트 주소 크기를 사용하던 IBM의 메인프레임이 있었으며, IBM 메인프레임은 2000년이 되어서야 64비트 프로세서를 포함했다. 1990년대 동안 여러 저가형 64비트 마이크로프로세서가 가전제품과 임베디드 애플리케이션에 사용되었다. 특히 닌텐도 64와 플레이스테이션 2는 개인용 컴퓨터에 도입되기 전에 64비트 마이크로프로세서를 탑재했다. 고성능 프린터, 네트워크 장비, 산업용 컴퓨터도 퀀텀 이펙트 디바이시스의 R5000과 같은 64비트 마이크로프로세서를 사용했다. 64비트 컴퓨팅은 2003년부터 애플의 매킨토시 제품군 일부 모델이 파워PC 970 프로세서(애플은 G5라 명명)로 전환하고, AMD가 최초의 64비트 X86-64 프로세서를 출시하면서 개인용 컴퓨터 데스크톱으로 점차 확산되었다. 물리적 메모리는 결국 32비트 한계를 따라잡았다. 2023년 기준으로 노트북 컴퓨터는 일반적으로 16GB를, 서버는 64GB 이상의 메모리를 장착하여, 32비트의 4GB 주소 수용량을 크게 초과했다.

64비트 데이터 타임라인

1961년
IBM이 64비트 데이터 워드와 32비트 또는 64비트 명령어 워드를 사용하는 IBM 7030 스트레치 슈퍼컴퓨터를 출시.
1974년
컨트롤 데이터 코퍼레이션이 64비트 워드 아키텍처를 사용하는 CDC Star-100 벡터 슈퍼컴퓨터를 출시 (이전 CDC 시스템은 60비트 아키텍처 기반).
인터내셔널 컴퓨터즈 리미티드가 32비트, 64비트, 128비트 2의 보수 정수, 64비트 및 128비트 부동 소수점, 32비트, 64비트, 128비트 팩형 십진수 및 128비트 누산기 레지스터를 갖춘 ICL 2900 시리즈를 출시. 이 아키텍처는 이후 여러 ICL 및 후지쯔 머신을 거쳐 생존함. 최신 기종인 후지쯔 슈퍼노바는 64비트 인텔 프로세서에서 원래 환경을 에뮬레이션함.
1976년
크레이 리서치가 64비트 워드 아키텍처를 기반으로 하며 이후 크레이 벡터 슈퍼컴퓨터의 기초가 될 첫 크레이-1 슈퍼컴퓨터를 출시.
1983년
Elxsi가 Elxsi 6400 병렬 미니슈퍼컴퓨터를 출시. Elxsi 아키텍처는 64비트 데이터 레지스터를 가졌으나 32비트 주소 공간을 가짐.
1989년
인텔이 인텔 i860 축소 명령어 집합 컴퓨터(RISC) 프로세서를 도입. "64비트 마이크로프로세서"로 마케팅되었으나 실제로는 32비트 아키텍처에 64비트 정수 연산이 가능한 3D 그래픽 유닛이 강화된 형태였음.
1993년
아타리가 아키텍처에 64비트 폭의 데이터 경로 일부를 포함하는 아타리 재규어 비디오 게임 콘솔을 도입.

64비트 주소 타임라인

1991년
MIPS 테크놀로지스가 자사 MIPS 아키텍처의 세 번째 개정판인 MIPS III 아키텍처를 구현한 최초의 64비트 마이크로프로세서인 R4000을 생산. 이 CPU는 SGI 그래픽 워크스테이션에서 IRIS Crimson부터 사용됨. 켄달 스퀘어 리서치가 OSF/1을 실행하는 독점적인 64비트 RISC 프로세서 아키텍처 기반의 첫 KSR1 슈퍼컴퓨터를 출시.
1992년
디지털 이큅먼트 코퍼레이션(DEC)이 PRISM 프로젝트에서 탄생한 순수 64비트 알파 아키텍처를 도입.
1994년
인텔이 32비트 IA-32 프로세서의 후속작으로 (휴렛 팩커드와 공동 개발한) 64비트 IA-64 아키텍처 계획을 발표. 1998~1999년 출시를 목표로 함.
1995년
썬 마이크로시스템즈가 64비트 SPARC 프로세서인 울트라스팍을 출시. 후지쯔 소유의 HAL 컴퓨터 시스템즈가 64비트 CPU인 1세대 SPARC64 기반 워크스테이션을 출시. IBM이 최초의 64비트 파워PC AS 프로세서인 A10 및 A30을 출시. IBM은 또한 운영체제, 데이터베이스, 애플리케이션을 변환할 수 있는 64비트 AS/400 시스템 업그레이드를 출시.
1996년
닌텐도가 MIPS R4000의 저가형 변종을 기반으로 한 닌텐도 64 비디오 게임 콘솔을 도입. HP가 64비트 PA-RISC 2.0 아키텍처의 첫 구현인 PA-8000을 출시.
1998년
IBM이 풀 64비트 파워PC/POWER 프로세서 제품군인 POWER3를 출시.
1999년
인텔이 IA-64 아키텍처용 명령어 집합을 출시. AMD가 X86-64(이후 AMD64로 브랜드화)라고 불리는 IA-32용 64비트 확장 세트를 공개적으로 발표.
2000년
IBM이 32비트 System/360 아키텍처의 후손인 32비트 ESA/390 아키텍처의 64비트 버전인 Z/아키텍처 기반의 첫 64비트 메인프레임, zSeries z900을 출하.
2001년
인텔이 시장 출시 지연 끝에 IA-64 프로세서 라인을 출하. 현재 아이테니엄으로 브랜드화되어 고성능 서버를 타겟팅했으나 판매량이 기대에 미치지 못함.
2003년
AMD가 최초의 x86 기반 64비트 프로세서 아키텍처인 AMD64 아키텍처를 기반으로 하는 옵테론 및 애슬론 64 프로세서 라인을 도입. 애플 또한 IBM에서 생산한 64비트 "G5" 파워PC 970 CPU를 탑재한 제품을 출시. 인텔은 아이테니엄 칩이 자사의 유일한 64비트 프로세서로 남을 것이라고 주장.
2004년
인텔이 AMD의 시장 성공에 대응하여 IA-32e(나중에 EM64T, 이후 인텔 64로 이름 변경)라는 이름의 AMD64 확장 복제품을 개발했음을 인정. 인텔은 새로운 64비트 명령어 집합을 지원하는 제온 및 펜티엄 4 프로세서 제품군을 업데이트하여 출하.
비아 테크놀로지스가 Isaiah 64비트 프로세서를 발표.
2006년
소니, IBM, 도시바가 플레이스테이션 3, 서버, 워크스테이션 및 기타 기기에 사용될 64비트 셀 프로세서 제조를 시작. 인텔은 모바일, 데스크톱, 워크스테이션 제품군을 위한 최초의 주류 x86-64 프로세서로 코어 2 듀오를 출시. 이전 64비트 확장 프로세서 제품군은 소비자 소매 시장에서 널리 이용 가능하지 않았으며(64비트 펜티엄 4/D 대부분은 OEM), 64비트 펜티엄 4, 펜티엄 D, 셀러론은 수율 문제로 2006년 말까지 대량 생산되지 못함(양품 웨이퍼 대부분은 서버와 메인프레임을 목표로 했고 주류 시장은 2006년까지 130nm 32비트 프로세서 라인에 머물렀음). AMD가 최초의 64비트 모바일 프로세서를 90nm 공정으로 출시.
2011년
ARM 홀딩스가 ARM 아키텍처의 첫 64비트 버전인 ARMv8-A를 발표.
2012년
ARM 홀딩스가 2012년 10월 30일, 64비트 아키텍처 기반의 첫 코어인 Cortex-A53과 Cortex-A57 코어를 발표.
2013년
애플이 스마트폰 최초의 64비트 프로세서인 A7 ARMv8-A 기반 시스템 온 칩(SoC)을 탑재한 아이폰 5S를 발표하고, 64비트 프로세서를 탑재한 최초의 태블릿인 아이패드 에어와 아이패드 미니 2 레티나 디스플레이를 출시.
2014년
32비트 및 64비트 지원을 모두 포함한 RISC-V가 공개됨. 구글이 64비트 테그라 K1 칩으로 구동되는 최초의 안드로이드 기기인 넥서스 9 태블릿을 발표.
2015년
애플이 A8 ARMv8-A 기반 SoC를 탑재한 최초의 아이팟 터치인 아이팟 터치 (6세대)와, 최초의 64비트 프로세서 기반 Apple TV인 Apple TV (4세대)를 발표.
2018년
애플이 S4 ARMv8-A 기반 SoC를 탑재한 최초의 애플 워치인 애플 워치 시리즈 4를 발표.
2020년
시놉시스가 ARC ISA의 첫 64비트 버전인 ARCv3 ISA를 발표. 애플이 32비트 애플리케이션 지원을 중단한 애플 M1을 출시.
2023년
퀄컴이 32비트 ARM 애플리케이션 지원을 중단한 스냅드래곤 8 Gen 3와 스냅드래곤 X 엘리트를 출시.

64비트 운영체제 타임라인

1985년
크레이가 유닉스 운영체제의 첫 64비트 구현인 UNICOS를 출시.
1993년
DEC이 알파 아키텍처 기반 시스템을 위한 64비트 유닉스 계열 운영체제인 DEC OSF/1 AXP(이후 Tru64 UNIX로 개명)를 출시.
1994년
실리콘 그래픽스가 IRIX 운영체제 6.0 버전에 R8000 프로세서 지원을 추가.
1995년
DEC이 알파용 첫 풀 64비트 OpenVMS 버전인 OpenVMS 7.0을 출시. 알파 아키텍처를 위한 첫 64비트 리눅스 배포판이 출시됨.
1996년
실리콘 그래픽스가 IRIX 운영체제 6.2 버전에 R4x00 프로세서의 64비트 모드 지원을 추가.
1998년
썬 마이크로시스템즈가 풀 64비트 울트라스팍 지원을 갖춘 솔라리스 7을 출시.
2000년
IBM이 새로운 zSeries 64비트 메인프레임을 위한 MVS의 후손인 64비트 운영체제 Z/OS를 출시; 64비트 Linux on z Systems가 CPU 출시 직후 뒤따름.
2001년
리눅스가 X86-64를 완전히 지원하는 최초의 OS 커널이 됨(아직 X86-64 프로세서가 출시되지 않아 시뮬레이터에서 실행).
2001년
마이크로소프트가 아이테니엄의 IA-64 아키텍처를 위한 윈도우 XP 프로페셔널 x64 에디션을 출시; 실행 계층을 통해 32비트 응용 프로그램을 실행할 수 있었음.
2003년
애플이 파워PC 970 프로세서에서 네이티브 64비트 정수 연산 지원을 추가한 맥 OS X 10.3 "팬더" 운영체제를 출시. 여러 리눅스 배포판이 AMD64 지원을 포함하여 출시됨. FreeBSD가 AMD64 지원을 포함하여 출시됨.
2005년
1월 4일, 마이크로소프트는 전년 9월 이후 IA-64 프로세서 PC가 없었다는 이유로 윈도우 XP 프로페셔널 x64 에디션을 단종하고, 이를 대체하기 위해 윈도우의 x86-64 버전을 개발 중이라고 발표. 1월 31일, 썬 마이크로시스템즈가 AMD64 및 EM64T 프로세서를 지원하는 솔라리스 10을 출시. 4월 29일, 애플이 파워PC 970 프로세서 탑재 기기에서 64비트 명령줄 애플리케이션에 대한 제한적 지원을 제공하는 맥 OS X 10.4 "타이거"를 출시; 인텔 기반 맥을 위한 이후 버전들은 EM64T 프로세서 탑재 맥에서 64비트 명령줄 애플리케이션을 지원함. 4월 30일, 마이크로소프트가 AMD64 및 EM64T 프로세서를 위한 윈도우 XP 프로페셔널 x64 에디션 및 윈도우 서버 2003 x64 에디션을 출시.
2006년
마이크로소프트가 32비트 호환성을 유지하면서 AMD64/EM64T 프로세서를 위한 64비트 버전을 포함하는 윈도우 비스타를 출시. 64비트 버전에서는 모든 윈도우 애플리케이션과 구성 요소가 64비트이나, 호환성을 위해 플러그인 등 여러 32비트 버전도 포함됨.
2007년
애플이 파워PC 970 또는 EM64T 프로세서 탑재 기기에서 64비트 애플리케이션을 완전히 지원하는 맥 OS X 10.5 "레퍼드"를 출시.
2009년
마이크로소프트가 윈도우 비스타와 마찬가지로 AMD64/인텔 64 프로세서를 위한 풀 64비트 버전을 포함하는 윈도우 7을 출시; 대부분의 새 컴퓨터에는 64비트 버전이 기본 탑재됨. 마이크로소프트는 또한 최초의 64비트 전용 서버 운영체제인 윈도우 서버 2008 R2를 출시. 애플은 AMD64/인텔 64 프로세서용 64비트 커널을 탑재한 맥 OS X 10.6 "스노 레퍼드"를 출시했으나, 일부 최신 맥 모델만 64비트 커널을 기본으로 실행함. 맥 OS X 10.6에 번들된 대부분의 애플리케이션도 이제 64비트임.
2010년
윈도우 7 (64비트)이 윈도우 XP (32비트)를 제치고 Steam에서 가장 인기 있는 운영체제가 됨.
2011년
애플이 지원 기기에서 기본적으로 64비트 커널을 실행하는 맥 OS X 10.7 "라이언"을 출시. 64비트 커널을 실행할 수 없는 구형 기기는 32비트 커널로 실행되지만, 이전 릴리스와 마찬가지로 64비트 애플리케이션은 여전히 실행 가능함; 라이언은 32비트 프로세서 탑재 기기를 지원하지 않음. 아이튠즈를 포함하여 맥 OS X 10.7에 번들된 거의 모든 애플리케이션이 이제 64비트임.
2012년
마이크로소프트가 UEFI Class 3(CSM 없는 UEFI) 및 보안 부팅을 지원하는 윈도우 8을 출시. 애플이 OS X 마운틴 라이언을 출시하여 이전까지 지원되지 않던 일부 구형 기기에서 64비트 커널을 기본값으로 설정하고 32비트 커널을 제거함.
2018년
애플이 64비트 지원을 도입한 첫 watchOS 버전인 watchOS 5를 출시.
2019년
애플이 32비트 인텔 애플리케이션 지원을 중단한 macOS 10.15 "카탈리나"를 출시.
2021년
마이크로소프트가 10월 5일, IA-32 및 AArch32 시스템 지원을 중단하고 64비트 시스템만 지원하는 윈도우 11을 출시.
2022년
구글이 32비트 애플리케이션 지원을 중단한 픽셀 7을 출시. 애플이 애플 워치 시리즈 4 이상, 애플 워치 SE(1세대) 이상 및 신규 출시된 애플 워치 울트라 등 64비트 프로세서 탑재 애플 워치 모델에서만 독점적으로 실행되는 첫 watchOS 버전인 watchOS 9를 출시하고, 마지막 32비트 프로세서 탑재 모델인 애플 워치 시리즈 3에 대한 지원을 중단.
2023년
구글이 32비트 애플리케이션 지원을 중단한 안드로이드 14를 출시.
2024년
마이크로소프트가 윈도우 11 2024 업데이트를 출시, ARM 버전에서 32비트 ARM 애플리케이션 지원을 중단.

프로세서의 한계

이론적으로 64비트 마이크로프로세서는 16 엑사바이트(16 × 10246 = 264 = 18,446,744,073,709,551,616 바이트)의 메모리를 주소 지정할 수 있다. 하지만 모든 명령어 집합과 해당 명령어 집합을 구현하는 모든 프로세서가 전체 64비트 가상 또는 물리적 주소 공간을 지원하는 것은 아니다.

X86-64 아키텍처(2024년 3월월 기준)는 가상 메모리에 48비트, 각 프로세서에 대해 최대 52비트의 물리적 메모리를 허용한다. 이러한 제한으로 각각 256 테라바이트(256 × 10244 바이트)와 4 페타바이트(4 × 10245 바이트)의 메모리 크기가 허용된다. PC는 현재 (메모리 칩의 물리적 크기 때문에) 4 페타바이트의 메모리를 담을 수 없지만, AMD는 가까운 미래에 이에 근접할 수 있는 대규모 서버, 공유 메모리 클러스터 및 기타 물리적 주소 공간 사용 사례를 구상했다. 따라서 52비트 물리 주소는 완전한 64비트 물리 주소를 구현하는 비용을 들이지 않고도 확장을 위한 충분한 공간을 제공한다. 마찬가지로 48비트 가상 주소 공간은 32비트 제한인 4GB(4 × 10243 바이트)의 65,536(216)배를 제공하도록 설계되었으며, 나중의 확장을 위한 공간을 마련하고 완전한 64비트 주소 번역에 따른 오버헤드를 발생시키지 않도록 설계되었다.

Power ISA v3.0은 64비트 유효 주소를 허용하며, 이는 가상 메모리를 위해 65~78비트가 허용되는 세그먼트 주소로 매핑되고, 각 프로세서에 대해 물리적 메모리를 위해 최대 60비트를 허용한다.

오라클 SPARC 아키텍처 2015는 가상 메모리에 64비트를 허용하고, 각 프로세서에 대해 물리적 메모리에 40~56비트를 허용한다.

ARM AArch64 가상 메모리 시스템 아키텍처는 가상 메모리에 48~56비트, 각 프로세서에 대해 물리적 메모리에 32~56비트를 허용한다.

DEC 알파 사양은 최소 43비트의 가상 메모리 주소 공간(8TB)을 지원해야 하며, 하드웨어는 나머지 지원되지 않는 비트가 0인 경우 이를 체크하고 트랩해야 한다(향후 프로세서에서의 호환성을 지원하기 위함). 알파 21064는 43비트 가상 메모리 주소 공간(8TB)과 34비트 물리적 메모리 주소 공간(16GB)을 지원했다. 알파 21164는 43비트 가상 메모리 주소 공간(8TB)과 40비트 물리적 메모리 주소 공간(1TB)을 지원했다. 알파 21264는 사용자 구성 가능한 43비트 또는 48비트 가상 메모리 주소 공간(8TB 또는 256TB)과 44비트 물리적 메모리 주소 공간(16TB)을 지원했다.

64비트 응용 프로그램

32비트 vs 64비트

32비트에서 64비트 아키텍처로의 변경은 근본적인 변화인데, 대부분의 운영체제가 소프트웨어를 통해 실제 메모리 주소 지정 하드웨어를 관리해야 하므로 새 아키텍처를 활용하려면 광범위하게 수정되어야 하기 때문이다. 기타 소프트웨어도 새로운 기능을 사용하도록 이식되어야 한다. 구형 32비트 소프트웨어는 64비트 명령어 집합이 32비트 명령어 집합의 상위 집합이어서 64비트 명령어 집합을 지원하는 프로세서가 32비트 명령어 집합용 코드도 실행할 수 있거나, 소프트웨어 에뮬레이션을 통하거나, 또는 인텔의 일부 아이테니엄 프로세서처럼 32비트 X86 애플리케이션을 실행하기 위해 64비트 프로세서 내에 실제 32비트 프로세서 코어를 구현함으로써 지원될 수 있다. 해당 64비트 아키텍처용 운영체제는 일반적으로 32비트 및 64비트 애플리케이션을 모두 지원한다.

이에 대한 중요한 예외 사례는 IBM AS/400으로, 이를 위한 소프트웨어는 TIMI(Technology Independent Machine Interface)라는 가상 명령어 집합 구조(ISA)로 컴파일된다. TIMI 코드는 실행 전에 저수준 소프트웨어에 의해 네이티브 기계어로 번역된다. IBM이 AS/400의 네이티브 명령어 집합을 구형 32/48비트 IMPI에서 Amazon이라는 코드명의 신형 64비트 파워PC-AS로 전환했을 때처럼, 전체 운영체제와 모든 소프트웨어를 새 플랫폼으로 옮기려면 번역 소프트웨어만 다시 작성하면 된다. IMPI 명령어 집합은 32비트 파워PC와도 완전히 달랐기에, 이 전환은 명령어 집합을 32비트에서 64비트로 옮기는 것보다 훨씬 큰 규모의 작업이었다.

X86-64 아키텍처(AMD64)를 사용하는 64비트 하드웨어에서는 대부분의 32비트 운영체제와 애플리케이션을 호환성 문제 없이 실행할 수 있다. 64비트 아키텍처의 더 큰 주소 공간은 디지털 영상, 과학 컴퓨팅, 대규모 데이터베이스와 같은 애플리케이션에서 대용량 데이터 세트를 더 쉽게 다룰 수 있게 해주지만, 64비트 아키텍처나 그들의 32비트 호환성 모드가 다른 작업에서 가격 대비 성능이 비슷한 32비트 시스템보다 빠를지에 대해서는 상당한 논쟁이 있었다.

컴파일된 자바 프로그램은 수정 없이 32비트 또는 64비트 자바 가상 머신에서 실행될 수 있다. char, short, int, long, float, double과 같은 모든 내장 유형과 배열 인덱스로 사용할 수 있는 유형의 길이와 정밀도는 표준에 의해 지정되며 기본 아키텍처에 의존하지 않는다. 64비트 자바 가상 머신에서 실행되는 자바 프로그램은 더 큰 주소 공간에 접근할 수 있다.

32비트와 64비트 프로세서를 비교할 때 속도만이 고려할 유일한 요소는 아니다. 멀티태스킹, 스트레스 테스트, 클러스터링과 같은 애플리케이션은 적절히 배포되었을 때 64비트 아키텍처에 더 적합할 수 있다. 이러한 이유로 64비트 클러스터는 IBM, HP, 마이크로소프트와 같은 대규모 조직에서 널리 배포되어 왔다.

요약:

  • 64비트 프로세서는 64비트 소프트웨어에서 가장 잘 작동한다.
  • 64비트 프로세서는 하위 호환성을 가질 수 있어 32비트 명령어 집합 버전에 대한 32비트 응용 프로그램 소프트웨어를 실행할 수 있으며, 32비트 명령어 집합 버전에 대한 32비트 운영체제 실행도 지원할 수 있다.
  • 32비트 프로세서는 64비트 소프트웨어와 호환되지 않는다.

장점과 단점

일반적인 오해 중 하나는 컴퓨터가 4 GB 이상의 랜덤 액세스 메모리를 가지고 있지 않으면 64비트 아키텍처가 32비트 아키텍처보다 나을 것이 없다는 것이다. 이는 완전히 사실이 아니다.

  • 일부 운영체제와 특정 하드웨어 구성은 IA-32 시스템에서 3~4GB 영역이 하드웨어 주소 지정을 위해 예약되어 있기 때문에 물리적 메모리 공간을 3GB로 제한한다(참조: 3 GB barrier); 64비트 아키텍처는 4GB보다 훨씬 더 많은 메모리를 주소 지정할 수 있다. 그러나 펜티엄 프로부터의 IA-32 프로세서는 물리 주소 확장(PAE)을 사용하여 36비트 물리적 메모리 주소 공간을 허용하며, 이는 64GB 물리적 주소 범위를 제공하고 그중 최대 62GB까지 메인 메모리로 사용할 수 있다. PAE를 지원하는 운영체제는 IA-32 프로세서에서도 4GB 물리적 메모리로 제한되지 않을 수 있다. 하지만 드라이버와 기타 커널 모드 소프트웨어(특히 구형 버전)는 PAE와 호환되지 않을 수 있는데, 이것이 마이크로소프트 윈도우의 32비트 버전이 4GB 물리적 RAM으로 제한되는 이유로 거론되어 왔다. (다만 이 설명의 타당성에 대해서는 논란이 있다).
  • 일부 운영체제는 프로세스 주소 공간의 일부를 OS 사용을 위해 예약하며, 이는 사용자 프로그램을 위한 메모리 매핑 가용 주소 공간을 효과적으로 줄인다. 예를 들어, 32비트 윈도우는 커널을 위해 총 주소 공간의 1~2GB(설정에 따라 다름)를 예약하며, 이는 사용자 모드를 위해 단 3GB 또는 2GB의 주소 공간만을 남긴다. 이 제한은 64비트 운영체제에서 훨씬 높다.
  • 4GB 이상의 파일이 보편화됨에 따라 메모리 맵 파일은 32비트 아키텍처에서 구현하기 어려워지고 있다. 그러한 대용량 파일은 32비트 아키텍처에 쉽게 메모리 매핑될 수 없는데, 한 번에 파일의 일부만 주소 공간에 매핑할 수 있고 메모리 매핑으로 파일에 접근하려면 매핑된 부분을 필요에 따라 주소 공간으로 스와핑해야 하기 때문이다. 운영체제에 의해 적절히 구현될 경우 메모리 매핑이 가장 효율적인 디스크-메모리 방식 중 하나라는 점에서 이는 문제이다.
  • 인코더, 디코더, 암호화 소프트웨어와 같은 일부 64비트 프로그램은 64비트 레지스터로부터 큰 이득을 볼 수 있는 반면, 3D 그래픽 지향 프로그램 등 다른 프로그램의 성능은 32비트에서 64비트 환경으로 전환해도 영향을 받지 않는 경우가 있다.
  • X86-64 및 AArch64와 같은 일부 64비트 아키텍처는 (워드 길이와 직접적인 관련은 없지만) 32비트 대응 장치보다 더 많은 범용 레지스터를 지원한다. 이는 프로세서가 데이터를 캐시나 메인 메모리에서 가져올 필요가 없고 가용 레지스터에 데이터를 저장할 수 있다면 루프에 대해 상당한 속도 향상으로 이어진다.
C 언어 예시:
int a, b, c, d, e;
for (a = 0; a < 100; a++) {
    b = a;
    c = b;
    d = c;
    e = d;
}
이 코드는 먼저 5개의 값(a, b, c, d, e)을 생성하고 루프에 넣는다. 루프 동안 이 코드는 b의 값을 a의 값으로, c의 값을 b의 값으로, d의 값을 c의 값으로, e의 값을 d의 값으로 변경한다. 이는 모든 값을 a로 변경하는 것과 동일한 효과를 낸다.
프로세서가 레지스터에 두세 개의 값이나 변수만 보관할 수 있다면, d와 e 변수까지 처리하기 위해 메모리와 레지스터 사이에서 값을 이동시켜야 하며 이는 많은 CPU 사이클을 소요하는 과정이다. 모든 값과 변수를 레지스터에 유지할 수 있는 프로세서는 반복할 때마다 레지스터와 메모리 사이에서 데이터를 이동시킬 필요 없이 루프를 처리할 수 있다. 이 동작은 컴파일러에 따라 결과가 달라질 수 있지만 가상 메모리와 쉽게 비교될 수 있다.

64비트 아키텍처의 주된 단점은 32비트 아키텍처에 비해 동일한 데이터가 메모리에서 더 많은 공간을 차지한다는 점이다(긴 포인터와 기타 데이터 형식, 정렬 패딩 때문). 이는 특정 프로세스의 메모리 요구량을 증가시키며 효율적인 프로세서 캐시 사용에 영향을 줄 수 있다. 부분적인 32비트 모델을 유지하는 것은 이를 처리하는 한 방법이며 일반적으로 상당히 효과적이다. 예를 들어, Z/OS 운영체제는 프로그램 코드가 31비트 주소 공간(하위 기반 하드웨어 플랫폼의 주소 계산에서는 상위 비트가 사용되지 않음)에 상주하도록 요구하고 데이터 객체는 선택적으로 64비트 영역에 상주하도록 하는 방식을 취한다. 모든 애플리케이션이 대규모 주소 공간을 필요로 하거나 64비트 데이터 항목을 조작하는 것은 아니므로, 이러한 애플리케이션은 해당 기능으로부터 이득을 보지 못한다.

소프트웨어 가용성

x86 기반 64비트 시스템은 종종 32비트 아키텍처용으로 작성된 소프트웨어의 대안이 부족하다. 마이크로소프트 윈도우에서 가장 심각한 문제는 구형 하드웨어용 장치 드라이버 호환성이다. 대부분의 32비트 응용 소프트웨어는 WoW64 기술과 같은 호환성 모드(에뮬레이션 모드)를 통해 64비트 운영체제에서 실행될 수 있다. 64비트 윈도우 네이티브 모드 드라이버 환경은 32비트 Win32 서브시스템 코드를 호출할 수 없는 64비트 NTDLL.DLL 위에서 실행된다(Winprinters처럼 실제 하드웨어 기능이 사용자 모드 소프트웨어에서 에뮬레이션되는 장치들). 2007년 초(비스타 x64)까지 대부분의 장치용 64비트 드라이버를 구할 수 없었기 때문에 64비트 윈도우를 사용하는 것은 도전으로 간주되었다. 그러나 메모리 가격이 하락하고 4GB 이상의 RAM 사용이 증가하면서 64비트 컴퓨팅으로 트렌드가 이동했다. 대부분의 제조사가 신규 장치에 대해 32비트 및 64비트 드라이버를 모두 제공하기 시작하면서 64비트 드라이버의 부재 문제는 해결되었다. 64비트 드라이버가 제공되지 않는 많은 구형 장치는 결과적으로 64비트 시스템에서 사용할 수 없게 되었다.

오픈 소스 드라이버의 경우 32비트 드라이버를 64비트용으로 수정할 수 있어 드라이버 호환성 문제가 덜했다. 2007년 초 이전에 만들어진 하드웨어에 대한 지원은 사용자 수가 상대적으로 적어 오픈 소스 플랫폼에서도 문제가 되었다.

64비트 버전의 윈도우는 16비트 응용 프로그램을 실행할 수 없다. 하지만 대부분의 32비트 애플리케이션은 잘 작동한다. 64비트 사용자는 16비트 애플리케이션을 실행하거나 NTVDM의 대안을 사용하기 위해 16비트 또는 32비트 운영체제의 가상 머신을 설치해야 한다.

맥 OS X 10.4 "타이거"와 맥 OS X 10.5 "레퍼드"는 32비트 커널만 가졌지만, 64비트 프로세서에서 64비트 사용자 모드 코드를 실행할 수 있었다. 맥 OS X 10.6 "스노 레퍼드"는 32비트 및 64비트 커널을 모두 가졌고, 대부분의 맥에서 64비트 프로세서에서도 32비트 커널을 사용했다. 이를 통해 해당 맥들은 64비트 프로세스를 지원하면서도 32비트 장치 드라이버를 지원할 수 있었으나, 64비트 드라이버와 그에 따른 성능 향상은 누릴 수 없었다. 맥 OS X 10.7 "라이언"은 더 많은 맥에서 64비트 커널로 실행되었으며, OS X 10.8 "마운틴 라이언" 및 이후 macOS 릴리스는 64비트 커널만 갖추고 있다. 64비트 프로세서가 탑재된 시스템에서 32비트 및 64비트 macOS 커널은 32비트 사용자 모드 코드를 실행할 수 있으며, macOS 모하비(10.14)까지의 모든 버전에는 32비트 애플리케이션이 사용하는 라이브러리의 32비트 버전이 포함되어 있어 32비트 사용자 모드 소프트웨어가 해당 시스템에서 실행된다. 라이브러리의 32비트 버전은 macOS 카탈리나(10.15)에서 애플에 의해 제거되었다.

리눅스와 대부분의 다른 유닉스 계열 운영체제, 그리고 그들을 위한 C 및 C++ 툴체인은 수년간 64비트 프로세서를 지원해 왔다. 해당 플랫폼을 위한 많은 애플리케이션과 라이브러리는 C 및 C++로 작성된 오픈 소스 소프트웨어이므로, 64비트 안전(64-bit-safe)하다면 64비트 버전으로 컴파일될 수 있다. 빈번한 릴리스를 강조하는 이러한 소스 기반 배포 모델 덕분에 해당 운영체제에서 애플리케이션 소프트웨어 가용성 문제는 덜한 편이다.

64비트 데이터 모델

32비트 프로그램에서 포인터와 정수 같은 데이터 형식은 일반적으로 동일한 길이를 가진다. 64비트 머신에서는 반드시 그렇지는 않다. C와 그 후손인 C++ 및 오브젝티브-C와 같은 프로그래밍 언어에서 데이터 형식을 혼용하면 32비트 구현에서는 작동할 수 있으나 64비트 구현에서는 작동하지 않을 수 있다.

64비트 머신의 C 및 C 파생 언어를 위한 많은 프로그래밍 환경에서 int 변수는 여전히 32비트 폭이지만 long 정수와 포인터는 64비트 폭이다. 이들은 "Long, Pointer, 64"의 약자인 LP64 데이터 모델을 가진다고 설명된다. 다른 모델로는 모든 데이터 형식 유형이 64비트 폭인 ILP64 데이터 모델과 short 정수도 64비트 폭인 SILP64 모델이 있다. 그러나 대부분의 경우 필요한 수정은 비교적 작고 간단하며, 잘 작성된 많은 프로그램은 변경 없이 새 환경에 대해 단순히 다시 컴파일될 수 있다. 또 다른 대안은 32비트 코드와의 호환성을 유지하기 위해 int와 long을 모두 32비트로 남겨두는 LLP64 모델이다. LL은 long long 정수 유형을 나타내며, 이는 32비트 환경을 포함한 모든 플랫폼에서 최소 64비트이다.

64비트 long long 정수를 추가한 ILP32 데이터 모델을 사용하는 64비트 프로세서 시스템도 있으며, 이는 32비트 프로세서가 탑재된 많은 플랫폼에서도 사용된다. 이 모델은 주소 공간이 훨씬 작아지는 대가로 코드 크기와 포인터를 포함하는 데이터 구조의 크기를 줄이며, 일부 임베디드 시스템에 좋은 선택이다. 64비트 명령어 집합 버전이 32비트 버전보다 더 많은 레지스터를 가지는 X86 및 ARM과 같은 명령어 집합의 경우, 공간적 불이익 없이 추가 레지스터에 접근할 수 있게 해준다. 이는 64비트 RISC 머신에서 일반적이며, X86에서는 X32 ABI로 탐구되었고, 최근에는 애플 워치 시리즈 4와 5에서 사용되었다.

64비트 데이터 모델
데이터
모델		 short
int		 int long
int		 long
long		 포인터,
size_t		 샘플 운영체제
ILP32 16 32 32 64 32 리눅스 시스템의 x32 및 arm64ilp32 ABI; MIPS N32 ABI.
LLP64 16 32 32 64 64 플랜 9, 마이크로소프트 윈도우 (X86-64, IA-64, ARM64) (비주얼 C++ 사용); 및 MinGW
LP64 16 32 64 64 64 대부분의 유닉스 및 유닉스 계열 시스템(예: 솔라리스, 리눅스, BSD, macOS). 윈도우 (시그윈 사용 시); Z/OS
ILP64 16 64 64 64 64 HAL 컴퓨터 시스템즈의 솔라리스 포트 (SPARC64용)
SILP64 64 64 64 64 64 클래식 UNICOS

프로그래밍 모델은 특정 컴파일러에 맞게 선택하는 것이며, 같은 운영체제 내에서 여러 모델이 공존할 수 있다. 그러나 운영체제 응용 프로그램 인터페이스(API)의 기본 모델로 선택된 프로그래밍 모델이 일반적으로 지배적이다.

또 다른 고려 사항은 장치 드라이버에 사용되는 데이터 모델이다. 드라이버는 대부분의 현대 운영체제 코드의 상당수를 차지하며(운영체제 실행 시 로드되지 않는 경우도 많음), 많은 드라이버가 데이터를 조작하기 위해 포인터를 많이 사용하고, 경우에 따라 직접 메모리 접근(DMA)을 위해 지원하는 하드웨어에 특정 크기의 포인터를 로드해야 한다. 예를 들어, 64비트 머신의 상위 영역 메모리에 DMA 데이터를 요청하는 32비트 PCI 장치용 드라이버는 운영체제로부터 장치에서 메모리로 데이터를 로드하라는 요청을 만족시킬 수 없는데, 해당 주소에 대한 포인터가 장치의 DMA 레지스터에 맞지 않기 때문이다. 이 문제는 운영체제가 드라이버에 DMA 요청을 생성할 때 장치의 메모리 제한을 고려하거나 IOMMU를 사용하여 해결한다.

현재 64비트 아키텍처

2023년 08월 기준 현재 제조되는 64비트 아키텍처용 프로세서는 다음과 같다:

동일 아키텍처의 32비트 버전에서 파생된 대부분의 64비트 아키텍처는 32비트 버전용 코드를 성능 저하 없이 네이티브로 실행할 수 있다. 예를 들어, X86-64 프로세서는 IA-32 애플리케이션을 최대 속도로 실행할 수 있다. 이러한 지원은 일반적으로 bi-arch 지원 또는 더 넓게 multi-arch 지원이라고 불린다.

같이 보기

각주

  1. ↑ 《Pentium Processor User's Manual Volume 1: Pentium Processor Data Book》 (PDF). 인텔. 1993.
  2. ↑ Sharma, Nitin Kumar; Yadav, K.P.; Sharma, B.K. “Comparative Study of the 64-bit and Apple families of Microprocessors” (PDF). 《International Journal of Innovative Technology and Exploring Engineering》 3 (2): 163–169. ISSN 2278-3075.
  3. ↑ “Cray-1 Computer System Hardware Reference Manual” (PDF). Cray Research. 1977. 2013년 10월 8일에 확인함.
  4. ↑ 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. Bibcode:1989ICGA....9d..85G. doi:10.1109/38.31467. S2CID 38831149. 2010년 11월 19일에 확인함.
  5. ↑ “i860 Processor Family Programmer's Reference Manual” (PDF). 인텔. 1991. 2019년 9월 12일에 확인함.
  6. ↑ “NEC Offers Two High Cost Performance 64-bit RISC Microprocessors” (보도자료). NEC. 1998년 1월 20일. 2011년 1월 9일에 확인함. Versions of the VR4300 processor are widely used in consumer and office automation applications, including the popular Nintendo 64틀:TM video game and advanced laser printers such as the recently announced, award-winning Hewlett-Packard LaserJet 4000 printer family.
  7. ↑ “MIPS R5000 Microprocessor Technical Backgrounder” (PDF). MIPS 테크놀로지스. 2024년 8월 19일에 확인함.
  8. ↑ “DDR5 | DRAM” (영어). 《Samsung Semiconductor Global》. 2025년 1월 19일에 확인함.
  9. ↑ “i860 64-Bit Microprocessor”. 인텔. 1989. 2011년 3월 19일에 원본 문서에서 보존된 문서. 2010년 11월 30일에 확인함.
  10. ↑ “Atari Jaguar History”. 《AtariAge》.
  11. ↑ Joe Heinrich (1994). 《MIPS R4000 Microprocessor User's Manual》 2판. MIPS 테크놀로지스.
  12. ↑ Richard L. Sites (1992). “Alpha AXP Architecture”. 《Digital Technical Journal》 (디지털 이큅먼트 코퍼레이션) 4 (4).
  13. ↑ Gwennap, Linley (1994년 10월 3일). “UltraSparc Unleashes SPARC Performance”. 《Microprocessor Report》 (MicroDesign Resources) 8 (13).
  14. ↑ Bishop, J. W. 외 (July 1996). “PowerPC AS A10 64-bit RISC microprocessor”. 《IBM Journal of Research and Development》 (IBM Corporation) 40 (4): 495–505. doi:10.1147/rd.404.0495.
  15. ↑ Gwennap, Linley (1994년 11월 14일). “PA-8000 Combines Complexity and Speed”. 《Microprocessor Report》 (MicroDesign Resources) 8 (15).
  16. ↑ F. P. O'Connell; S. W. White (November 2000). “POWER3: The next generation of PowerPC processors”. 《IBM Journal of Research and Development》 (IBM Corporation) 44 (6): 873–884. doi:10.1147/rd.446.0873.
  17. ↑ “VIA Unveils Details of Next-Generation Isaiah Processor Core” (보도자료). 비아 테크놀로지스. 2007년 10월 11일에 원본 문서에서 보존된 문서. 2007년 7월 18일에 확인함.
  18. ↑ “ARMv8 Technology Preview” (PDF). 2011년 10월 31일. 2011년 11월 11일에 원본 문서 (PDF)에서 보존된 문서. 2012년 11월 15일에 확인함.
  19. ↑ “ARM Launches Cortex-A50 Series, the World's Most Energy-Efficient 64-bit Processors” (보도자료). ARM 홀딩스. 2012년 10월 31일에 확인함.
  20. ↑ “ARM Keynote: ARM Cortex-A53 and ARM Cortex-A57 64bit ARMv8 processors launched”. 《ARMdevices.net》. 2012년 10월 31일.
  21. ↑ Asanović, Krste; Patterson, David A. (2014년 8월 6일). 《Instruction Sets Should Be Free: The Case For RISC-V》 (PDF). EECS Department, University of California, Berkeley. UCB/EECS-2014-146.
  22. ↑ “Synopsys Introduces New 64-bit ARC Processor IP”. 2022년 3월 31일에 원본 문서에서 보존된 문서.
  23. ↑ Stefan Berka. “Unicos Operating System”. www.operating-system.org. 2010년 11월 26일에 원본 문서에서 보존된 문서. 2010년 11월 19일에 확인함.
  24. ↑ Jon "maddog" Hall (2000년 6월 1일). “My Life and Free Software”. 《Linux Journal》.
  25. ↑ 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
  26. 1 2 John Siracusa (September 2009). “Mac OS X 10.6 Snow Leopard: the Ars Technica review”. 《Ars Technica》. 5쪽. 2009년 10월 9일에 원본 문서에서 보존된 문서. 2009년 9월 6일에 확인함.
  27. ↑ Joris Evers (2005년 1월 5일). “Microsoft nixes Windows XP for Itanium”. Computerworld. 2013년 6월 18일에 원본 문서에서 보존된 문서. 2017년 10월 17일에 확인함.
  28. ↑ “Microsoft Raises the Speed Limit with the Availability of 64-Bit Editions of Windows Server 2003 and Windows XP Professional” (보도자료). 마이크로소프트. 2005년 4월 25일. 2015년 9월 10일에 확인함.
  29. ↑ “Steam Hardware Survey”. 밸브 소프트웨어. 2010년 12월 4일. 2010년 12월 4일에 원본 문서에서 보존된 문서.
  30. ↑ “Windows 7 64-bit most used OS”. Bit-Tech. 2010년 8월 4일.
  31. ↑ “UEFI on Dell BizClient Platforms” (PDF).
  32. ↑ “AMD64 Programmer's Manual Volume 2: System Programming”. AMD. June 2025. 127쪽.
  33. ↑ “Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3A: System Programming Guide, Part 1” (PDF). 인텔. September 2016. p. 4-2.
  34. ↑ “Power ISA Version 3.0”. IBM. 2015년 11월 30일. 983쪽.
  35. ↑ “Oracle SPARC Architecture 2015 Draft D1.0.9” (PDF). 오라클. 2016년 11월 16일. 475쪽. 2020년 4월 22일에 원본 문서 (PDF)에서 보존된 문서.
  36. ↑ “ARM Architecture Reference Manual for A-profile architecture”. 2024년 11월 30일. section D8.1.6 "Implemented physical address size", section D8.1.8 "Supported virtual address ranges".
  37. ↑ Mashey, John (October 2006). “The Long Road to 64 Bits”. 《ACM Queue》 4 (8): 85–94. doi:10.1145/1165754.1165766.
  38. ↑ “Windows 7: 64 bit vs 32 bit?”. W7 Forums. 2009년 4월 2일. 2009년 4월 5일에 원본 문서에서 보존된 문서. 2009년 4월 5일에 확인함.
  39. ↑ “Frequently Asked Questions About the Java HotSpot VM”. 오라클 (기업). 2024년 12월 13일에 확인함.
  40. ↑ “A description of the differences between 32-bit versions of Windows Vista and 64-bit versions of Windows Vista”. 2011년 10월 15일에 원본 문서에서 보존된 문서. 2011년 10월 14일에 확인함.
  41. ↑ Mark Russinovich (2008년 7월 21일). “Pushing the Limits of Windows: Physical Memory”. 2017년 4월 7일에 원본 문서에서 보존된 문서. 2017년 3월 9일에 확인함.
  42. ↑ Chappell, Geoff (2009년 1월 27일). “Licensed Memory in 32-Bit Windows Vista”. 《geoffchappell.com》. WP:SPS. 2017년 3월 9일에 확인함.
  43. ↑ “Inside Native Applications”. Technet.microsoft.com. 2006년 11월 1일. 2010년 10월 23일에 원본 문서에서 보존된 문서. 2010년 11월 19일에 확인함.
  44. ↑ Lincoln Spector (2013년 8월 12일). “Run an old program on a new PC”.
  45. ↑ Peter Seebach (2006). “Exploring 64-bit development on POWER5: How portable is your code, really?”. 《IBM》.
  46. ↑ Henry Spencer. “The Ten Commandments for C Programmers”.
  47. ↑ “The Story of Thud and Blunder”. Datacenterworks.com. 2010년 11월 19일에 확인함.
  48. ↑ “ILP32 and LP64 data models and data type sizes”. 《z/OS XL C/C++ Programming Guide》.
  49. 1 2 3 “64-Bit Programming Models”. 2020년 6월 5일에 확인함.
  50. ↑ “Using the ILP64 Interface vs. LP64 Interface”. 《인텔》. 2025년 12월 19일에 확인함.
  51. 1 2 “Cray C/C++ Reference Manual”. August 1998. Table 9-1. Cray Research systems data type mapping. 2013년 10월 16일에 원본 문서에서 보존된 문서. 2013년 10월 15일에 확인함.
  52. 1 2 “Cray C and C++ Reference Manual (8.7) S-2179”. 2020년 6월 24일에 확인함.
  53. ↑ “Abstract Data Models - Windows applications”. 2018년 5월 30일.
  54. ↑ “ILP32 for AArch64 Whitepaper”. ARM Limited. 2015년 6월 9일. 2018년 12월 30일에 원본 문서에서 보존된 문서. 2018년 10월 9일에 확인함.
  55. ↑ “Apple devices in 2018”. woachk, security researcher. 2018년 10월 6일.
  56. ↑ “/usr/web/sources/plan9/sys/src/libmach/executable.c - Plan 9 from Bell Labs”. 《9p.io》. 2025년 8월 12일에 원본 문서에서 보존된 문서. 2026년 7월 8일에 확인함.
  57. ↑ stevewhims. “64-bit programming for Game Developers - Win32 apps” (미국 영어). 《learn.microsoft.com》. 2025년 10월 22일에 확인함.
내용주
  1. ↑ 부동 소수점 숫자와 같은.

외부 링크