64비트 컴퓨팅
Wikimedia Foundation, Inc. 블로그 포스트 번역
2002-11-17T16:51:55Z
개요
Computer architecture에서 64-bit integers, memory addresses, 또는 기타 data 단위는 64 bits 너비인 것들입니다. 또한 64-bit central processing units (CPU)와 arithmetic logic units (ALU)는 processor registers, address buses, 또는 data buses가 그 크기를 기반으로 하는 것들입니다. 이러한 프로세서를 사용하는 computer는 64-bit 컴퓨터입니다.
소프트웨어 관점에서 64-bit 컴퓨팅은 64-bit virtual memory 주소를 가진 machine code의 사용을 의미합니다. 그러나 모든 64-bit instruction set이 완전한 64-bit virtual memory 주소를 지원하는 것은 아닙니다. 예를 들어 x86-64와 AArch64는 virtual address의 48비트만 지원하며, 나머지 16비트의 virtual address는 모두 0(000...)이거나 모두 1(111...)이어야 하고, 여러 64-bit instruction set은 64비트 미만의 physical memory address를 지원합니다.
64-bit라는 용어는 또한 64-bit 프로세서가 표준인 컴퓨터 세대를 설명합니다. 64비트는 특정 컴퓨터 아키텍처, 버스, 메모리, CPU 클래스를 정의하는 word 크기이며, 확장하면 그 위에서 실행되는 소프트웨어도 정의합니다. 64-bit CPU는 1970년대부터 supercomputers에서 사용되었으며 (Cray-1, 1975), 1990년대 초부터 reduced instruction set computers (RISC) 기반 workstations과 servers에서 사용되었습니다. 2003년에 64-bit CPU는 x86-64 프로세서와 PowerPC G5 형태로 주류 PC 시장에 도입되었습니다.
64-bit register는 2^64 (18 quintillion 이상 또는 1.8×10^19)의 서로 다른 값을 보유할 수 있습니다. 64비트에 저장될 수 있는 integer 값의 범위는 사용된 integer representation에 따라 다릅니다. 가장 일반적인 두 가지 표현으로, 범위는 (unsigned) binary number로 표현할 때 0부터 18,446,744,073,709,551,615 (2^64 − 1)까지이고, two's complement로 표현할 때 −9,223,372,036,854,775,808 (−2^63)부터 9,223,372,036,854,775,807 (2^63 − 1)까지입니다. 따라서 64-bit memory 주소를 가진 프로세서는 2^64 바이트 (16 exabytes 또는 EB)의 byte-addressable 메모리에 직접 접근할 수 있습니다.
추가 한정 없이 64-bit computer architecture는 일반적으로 64비트 너비의 integer 및 addressing registers를 가지고 있어 64-bit 데이터 타입과 주소에 대한 직접 지원을 허용합니다. 그러나 CPU는 register와 다른 크기의 외부 data buses 또는 address buses를 가질 수 있으며, 더 클 수도 있습니다 (예를 들어 32-bit Pentium은 64-bit data bus를 가지고 있었습니다).
아키텍처 함의
Processor register는 일반적으로 여러 그룹으로 나뉩니다: integer, floating-point, single instruction, multiple data (SIMD), control, 그리고 종종 주소 산술을 위한 특수 register로 address, index, 또는 base registers와 같은 다양한 용도와 이름을 가질 수 있습니다. 그러나 현대 설계에서는 이러한 기능이 더 범용적인 integer register에 의해 수행되는 경우가 많습니다. 대부분의 프로세서에서 integer 또는 address-register만 메모리의 데이터를 주소 지정하는 데 사용될 수 있으며, 다른 유형의 register는 사용될 수 없습니다. 따라서 이러한 register의 크기는 일반적으로 직접 주소 지정 가능한 메모리의 양을 제한하며, floating-point register와 같이 더 넓은 register가 있더라도 마찬가지입니다.
대부분의 고성능 32-bit 및 64-bit 프로세서 (일부 주목할 만한 예외는 구형 또는 embedded ARM architecture (ARM)과 32-bit MIPS architecture (MIPS) CPU)는 integrated floating point 하드웨어를 가지고 있으며, 이는 종종 64-bit 데이터 단위를 기반으로 하지만 항상 그런 것은 아닙니다. 예를 들어 x86/x87 아키텍처는 메모리에서 64-bit (및 32-bit) floating-point 값을 로드하고 저장할 수 있는 명령어를 가지고 있지만, 내부 floating-point 데이터 및 register 형식은 80비트 너비이고, general-purpose register는 32비트 너비입니다. 대조적으로 64-bit Alpha 제품군은 64-bit floating-point 데이터 및 register 형식과 64-bit integer register를 사용합니다.
많은 컴퓨터 instruction sets는 단일 integer register가 컴퓨터의 물리적 또는 virtual memory의 모든 위치에 대한 memory address를 저장할 수 있도록 설계되었습니다. 따라서 메모리에 대한 총 주소 수는 종종 이러한 register의 너비에 의해 결정됩니다. 1960년대의 IBM System/360은 초기 32-bit 컴퓨터였습니다. 32-bit integer register를 가지고 있었지만 주소에 대해 word의 낮은 순서 24비트만 사용하여 16 MiB (16 × 1024^2 바이트)의 주소 공간을 초래했습니다. 32-bit superminicomputers (예: DEC VAX)는 1970년대에 일반화되었고, 32-bit microprocessors (예: Motorola 68000 family와 Intel 80386부터 시작하는 32-bit members of the x86 family)는 1980년대 중반에 나타났으며, 32비트를 편리한 register 크기의 de facto 합의로 만들었습니다.
32-bit address register는 2^32 주소 또는 4 GB의 random-access memory (RAM)를 참조할 수 있음을 의미했습니다. 이러한 아키텍처가 설계되었을 때 4 GB의 메모리는 설치된 일반적인 양 (4 MiB)을 훨씬 초과하여 주소 지정을 위한 충분한 headroom으로 간주되었습니다. 43억 개의 주소는 databases와 같은 애플리케이션에서 대부분의 엔티티에 고유한 참조를 할당하기에 충분하기 때문에 작업하기에 적절한 크기로 간주되었습니다.
1970년대와 1980년대의 일부 supercomputer 아키텍처 (예: Cray-1)는 최대 64비트 너비의 register를 사용했고 64-bit integer 산술을 지원했지만 64-bit 주소 지정을 지원하지 않았습니다. 1980년대 중반에 Intel i860 개발이 시작되어 1989년 출시로 정점에 달했습니다. i860은 32-bit integer register와 32-bit 주소 지정을 가지고 있어 완전한 64-bit 프로세서는 아니었지만, 그 그래픽 유닛은 64-bit integer 산술을 지원했습니다. 그러나 32비트는 1990년대 초까지 표준으로 남아 있었습니다. 메모리 비용의 지속적인 감소로 인해 4 GB에 접근하는 RAM 양의 설치가 증가했고, 4 GB 한계를 초과하는 virtual memory 공간의 사용이 특정 유형의 문제를 처리하기 위해 바람직해졌습니다. 이에 대응하여 MIPS와 DEC는 64-bit microprocessor 아키텍처를 개발했으며, 초기에는 고급 workstation과 server 머신을 위한 것이었습니다. 1990년대 중반까지 HAL Computer Systems, Sun Microsystems, IBM, Silicon Graphics, Hewlett-Packard는 그들의 workstation 및 server 시스템을 위한 64-bit 아키텍처를 개발했습니다. 이 추세의 주목할 만한 예외는 IBM의 mainframes였으며, 당시 32-bit 데이터와 31-bit 주소 크기를 사용했습니다. IBM mainframe은 2000년까지 64-bit 프로세서를 포함하지 않았습니다. 1990년대 동안 여러 저비용 64-bit microprocessor가 소비자 전자제품 및 embedded 애플리케이션에서 사용되었습니다. 특히 Nintendo 64와 PlayStation 2는 개인용 컴퓨터에 도입되기 전에 64-bit microprocessor를 가지고 있었습니다. 고급 프린터, 네트워크 장비, 산업용 컴퓨터도 Quantum Effect Devices R5000과 같은 64-bit microprocessor를 사용했습니다. 64-bit 컴퓨팅은 2003년부터 개인용 컴퓨터 데스크톱으로 천천히 내려오기 시작했습니다. Apple의 Macintosh 라인의 일부 모델이 PowerPC 970 프로세서 (Apple에서 G5라고 부름)로 전환되었을 때, Advanced Micro Devices (AMD)는 첫 번째 64-bit x86-64 프로세서를 출시했습니다. 물리적 메모리는 결국 32-bit 한계를 따라잡았습니다. 2023년에 노트북 컴퓨터는 일반적으로 16GB로 장착되었고 서버는 64 GB부터 시작하는 메모리로 장착되었으며, 이는 32비트의 4 GB 주소 용량을 크게 초과했습니다.
64-bit 데이터 타임라인
1961IBM은 64-bit 데이터 word와 32- 또는 64-bit instruction word를 사용하는 IBM 7030 Stretch supercomputer를 제공합니다.
1974Control Data Corporation은 64-bit word 아키텍처를 사용하는 CDC Star-100 vector supercomputer를 출시합니다 (이전 CDC 시스템은 60-bit 아키텍처를 기반으로 함).
International Computers Limited는 32-bit, 64-bit, 128-bit two's complement integers; 64-bit 및 128-bit floating point; 32-bit, 64-bit, 128-bit packed decimal 및 128-bit accumulator register를 가진 ICL 2900 Series를 출시합니다. 이 아키텍처는 ICL 및 Fujitsu 머신의 연속을 통해 생존했습니다. 최신 버전은 Fujitsu Supernova로, 64-bit Intel 프로세서에서 원래 환경을 에뮬레이트합니다.
1976Cray Research는 64-bit word 아키텍처를 기반으로 하는 첫 번째 Cray-1 supercomputer를 제공하며, 이는 나중의 Cray vector supercomputer의 기초를 형성합니다.
1983Elxsi는 64-bit 데이터 register를 가지지만 32-bit 주소 공간을 가진 Elxsi 6400 parallel minisupercomputer를 출시합니다.
1989Intel은 "64-Bit Microprocessor"로 마케팅되었지만 본질적으로 32-bit 아키텍처를 가진 Intel i860 reduced instruction set computer (RISC) 프로세서를 도입합니다. 64-bit integer 연산이 가능한 3D 그래픽 유닛으로 향상되었습니다.
64-bit 주소 타임라인
1991MIPS Computer Systems는 MIPS architecture의 세 번째 개정인 MIPS III 아키텍처를 구현하는 첫 번째 64-bit microprocessor인 R4000을 생산합니다. CPU는 SGI graphics workstations에서 IRIS Crimson부터 시작하여 사용됩니다. [Kendall Square Research](https://en.wikipedia.org/wiki/Kendall Square Research)는 OSF/1을 실행하는 독점 64-bit RISC 프로세서 아키텍처를 기반으로 한 첫 번째 KSR1 supercomputer를 제공합니다.
1994Intel은 32-bit IA-32 프로세서의 후속으로 64-bit IA-64 아키텍처 (Hewlett-Packard와 공동 개발)에 대한 계획을 발표합니다. 1998년부터 1999년의 출시 날짜가 목표였습니다.
1995Sun은 64-bit SPARC 프로세서인 UltraSPARC를 출시합니다. Fujitsu 소유의 HAL Computer Systems는 HAL의 독립적으로 설계된 첫 번째 세대 SPARC64를 기반으로 한 workstations을 출시합니다. IBM은 첫 번째 64-bit PowerPC AS 프로세서인 A10 및 A30 microprocessor를 출시합니다. IBM은 또한 operating system, database 및 애플리케이션을 변환할 수 있는 64-bit AS/400 시스템 업그레이드를 출시합니다.
1996Nintendo는 MIPS R4000의 저비용 변형을 중심으로 구축된 Nintendo 64 video game console을 도입합니다. HP는 64-bit PA-RISC 2.0 아키텍처의 첫 번째 구현인 PA-8000을 출시합니다.
1999Intel은 IA-64 아키텍처의 instruction set을 출시합니다. AMD는 IA-32에 대한 64-bit 확장 세트인 x86-64 (나중에 AMD64로 브랜드됨)를 공개적으로 공개합니다.
2000IBM은 첫 번째 64-bit z/Architecture mainframe인 zSeries z900을 배송합니다. z/Architecture는 32-bit System/360 아키텍처의 후손인 32-bit ESA/390 아키텍처의 64-bit 버전입니다.
2001Intel은 시장 진출에서 반복된 지연 후 IA-64 프로세서 라인을 배송합니다. 이제 Itanium으로 브랜드되고 고급 서버를 목표로 하며, 판매는 기대에 미치지 못합니다.
2003AMD는 첫 번째 x86 기반 64-bit 프로세서 아키텍처인 AMD64 아키텍처를 기반으로 한 Opteron과 Athlon 64 프로세서 라인을 도입합니다. Apple은 또한 IBM에서 생산한 64-bit "G5" PowerPC 970 CPU를 배송합니다. Intel은 Itanium 칩이 유일한 64-bit 프로세서로 남을 것이라고 주장합니다.
2004Intel은 AMD의 시장 성공에 반응하여 AMD64 확장의 클론인 IA-32e (나중에 EM64T로 이름 변경, 그 후 다시 Intel 64로 이름 변경)를 개발 중임을 인정합니다. Intel은 새로운 64-bit instruction set을 지원하는 Xeon과 Pentium 4 프로세서 제품군의 업데이트된 버전을 배송합니다.
2006Sony, IBM, Toshiba는 PlayStation 3, 서버, workstations 및 기타 기기에서 사용하기 위해 64-bit Cell processor를 제조하기 시작합니다. Intel은 모바일, 데스크톱 및 workstation 라인을 위한 첫 번째 주류 x86-64 프로세서인 Core 2 Duo를 출시합니다. 이전 64-bit 확장 프로세서 라인은 소비자 소매 시장에서 널리 사용 가능하지 않았습니다 (대부분의 64-bit Pentium 4/D는 OEM). 64-bit Pentium 4, Pentium D, Celeron은 수율 문제로 인해 2006년 말까지 대량 생산되지 않았습니다 (대부분의 좋은 수율 웨이퍼는 서버 및 mainframe을 목표로 했으며 주류는 2006년까지 130 nm 32-bit 프로세서 라인으로 남아 있었음). Core 2가 출시된 후 곧 저가형이 되었습니다. AMD는 첫 번째 64-bit 모바일 프로세서를 출시했으며 90 nm에서 제조했습니다.
2012ARM Holdings는 2012년 10월 30일에 64-bit 아키텍처를 기반으로 한 첫 번째 코어인 Cortex-A53 및 Cortex-A57 코어를 발표했습니다.
2013Apple은 스마트폰의 첫 번째 64-bit 프로세서인 iPhone 5S, Apple A7 ARMv8-A 기반 system-on-a-chip, 그리고 64-bit 프로세서를 가진 첫 번째 태블릿인 iPad Air와 iPad Mini 2를 발표합니다.
2014RISC-V는 32-bit 및 64-bit 지원 모두를 가지고 출시되었습니다. Google은 64-bit Tegra K1 칩에서 실행되는 첫 번째 Android 기기인 Nexus 9 태블릿을 발표합니다.
2015Apple은 64-bit 프로세서를 사용하는 첫 번째 iPod Touch인 iPod Touch (6th generation), Apple A8 ARMv8-A 기반 system-on-a-chip, 그리고 64-bit 프로세서를 사용하는 첫 번째 Apple TV인 Apple TV (4th generation)를 발표합니다.
2018Apple은 64-bit 프로세서를 사용하는 첫 번째 Apple Watch인 Apple Watch Series 4, Apple S4 ARMv8-A 기반 system-on-a-chip을 발표합니다.
2020Synopsis는 ARC ISA의 첫 번째 64-bit 버전인 ARCv3 ISA를 발표합니다. Apple은 32-bit 애플리케이션에 대한 지원이 부족한 Apple M1을 출시합니다.
64-bit 운영 체제 타임라인
1993DEC는 Alpha 아키텍처를 기반으로 한 시스템을 위해 64-bit DEC OSF/1 AXP Unix-like operating system (나중에 Tru64 UNIX로 이름 변경)을 출시합니다.
1995DEC는 Alpha를 위한 OpenVMS의 첫 번째 완전한 64-bit 버전인 OpenVMS 7.0을 출시합니다. Alpha 아키텍처를 위한 첫 번째 64-bit Linux distribution이 출시됩니다.
2000IBM은 새로운 zSeries 64-bit mainframes을 위해 MVS에서 내려온 64-bit operating system인 z/OS를 출시합니다. 64-bit Linux on z Systems는 CPU 출시 직후에 따릅니다.
2001Microsoft는 Itanium의 IA-64 아키텍처를 위해 Windows XP 64-Bit Edition을 출시합니다. execution layer를 통해 32-bit applications을 실행할 수 있습니다.
2003Apple은 PowerPC 970 프로세서에서 native 64-bit integer 산술에 대한 지원을 추가하는 Mac OS X 10.3 "Panther" operating system을 출시합니다. 여러 Linux distributions는 AMD64에 대한 지원으로 출시됩니다. FreeBSD는 AMD64에 대한 지원으로 출시됩니다.
20051월 4일, Microsoft는 Windows XP 64-Bit Edition을 중단합니다. IA-64 프로세서가 있는 PC는 이전 9월 이후 사용 가능하지 않았으며, x86-64 버전의 Windows를 개발 중임을 발표합니다. 1월 31일, Sun은 AMD64 및 EM64T 프로세서에 대한 지원을 가진 Solaris 10을 출시합니다. 4월 29일, Apple은 PowerPC 970 프로세서가 있는 머신에서 64-bit command-line 애플리케이션에 대한 제한된 지원을 제공하는 Mac OS X 10.4 "Tiger"를 출시합니다. Intel 기반 Mac의 나중 버전은 EM64T 프로세서가 있는 Mac에서 64-bit command-line 애플리케이션을 지원했습니다. 4월 30일, Microsoft는 AMD64 및 EM64T 프로세서를 위해 Windows XP Professional x64 Edition과 Windows Server 2003 x64 Edition을 출시합니다.
2006Microsoft는 AMD64/EM64T 프로세서를 위한 64-bit 버전을 포함하는 Windows Vista를 출시하며 32-bit 호환성을 유지합니다. 64-bit 버전에서 모든 Windows 애플리케이션 및 구성 요소는 64-bit이지만, 많은 것들은 plug-ins와의 호환성을 위해 32-bit 버전도 포함합니다.
2007Apple은 PowerPC 970 또는 EM64T 프로세서가 있는 머신에서 64-bit 애플리케이션을 완전히 지원하는 Mac OS X 10.5 "Leopard"를 출시합니다.
2009Microsoft는 Windows Vista와 마찬가지로 AMD64/Intel 64 프로세서를 위한 완전한 64-bit 버전을 포함하는 Windows 7을 출시합니다. 대부분의 새 컴퓨터는 기본적으로 64-bit 버전으로 로드됩니다. Microsoft는 또한 첫 번째 64-bit 전용 server operating system인 Windows Server 2008 R2를 출시합니다. Apple은 AMD64/Intel64 프로세서를 위한 64-bit kernel을 가진 Mac OS X 10.6 "Snow Leopard"를 출시합니다. 그러나 Apple 컴퓨터의 특정 최근 모델만 기본적으로 64-bit kernel을 실행합니다. Mac OS X 10.6과 함께 번들된 대부분의 애플리케이션은 이제 64-bit입니다.
2010Windows 7 (64-bit)은 Steam에서 가장 인기 있는 OS가 되어 Windows XP (32-bit)를 능가합니다.
2011Apple은 지원되는 머신에서 기본적으로 64-bit kernel을 실행하는 Mac OS X 10.7 "Lion"을 출시합니다. 64-bit kernel을 실행할 수 없는 구형 머신은 32-bit kernel을 실행하지만, 이전 출시와 마찬가지로 여전히 64-bit 애플리케이션을 실행할 수 있습니다. Lion은 32-bit 프로세서가 있는 머신을 지원하지 않습니다. Mac OS X 10.7과 함께 번들된 거의 모든 애플리케이션은 이제 64-bit이며, iTunes를 포함합니다.
2012Microsoft는 UEFI Class 3 (UEFI without CSM)과 Secure Boot를 지원하는 Windows 8을 출시합니다. Apple은 일부 구형 이전에 지원되지 않는 머신에서 64-bit kernel을 기본값으로 만들고 32-bit kernel을 제거하는 OS X Mountain Lion을 출시합니다.
2017Apple은 AArch64 프로세서가 있는 머신만 지원하는 iOS 11을 출시합니다. 64-bit 애플리케이션만 지원하는 64-bit kernel을 가지고 있습니다. 32-bit 애플리케이션은 더 이상 호환되지 않습니다.
2022Google은 32-bit 애플리케이션에 대한 지원을 중단하는 Pixel 7을 출시합니다. Apple은 64-bit 프로세서가 있는 Apple Watch 모델 (Apple Watch Series 4 이상, Apple Watch SE (1st generation) 이상 및 새로 도입된 Apple Watch Ultra)에서만 독점적으로 실행되는 첫 번째 watchOS 버전인 watchOS 9를 출시합니다. 32-bit 프로세서가 있는 마지막 Apple Watch 모델인 Apple Watch Series 3에 대한 지원을 중단합니다.
프로세서의 한계
원칙적으로 64-bit microprocessor는 16 EB (16 × 1024^6 = 2^64 = 18,446,744,073,709,551,616 바이트)의 메모리를 주소 지정할 수 있습니다. 그러나 모든 instruction set이 아니며, 이러한 instruction set을 구현하는 모든 프로세서가 완전한 64-bit virtual 또는 physical 주소 공간을 지원하는 것은 아닙니다.
x86-64 architecture (2024년 3월 기준)는 virtual memory에 48비트를 허용하고, 주어진 프로세서에 대해 physical memory에 최대 52비트를 허용합니다. 이러한 한계는 각각 256 TB (256 × 1024^4 바이트)와 4 PB (4 × 1024^5 바이트)의 메모리 크기를 허용합니다. PC는 현재 4 petabytes의 메모리를 포함할 수 없습니다 (메모리 칩의 물리적 크기 때문에). 그러나 AMD는 대규모 서버, shared memory 클러스터 및 가까운 미래에 이에 접근할 수 있는 physical 주소 공간의 기타 용도를 예상했습니다. 따라서 52-bit physical 주소는 완전한 64-bit physical 주소 구현의 비용을 발생시키지 않으면서 확장을 위한 충분한 여유를 제공합니다. 마찬가지로 48-bit virtual 주소 공간은 32-bit 한계인 4 GB (4 × 1024^3 바이트)의 65,536 (2^16)배를 제공하도록 설계되어 나중의 확장을 위한 여유를 제공하고 완전한 64-bit 주소 변환의 오버헤드를 발생시키지 않습니다.
Power ISA v3.0은 effective 주소에 64비트를 허용하며, virtual memory에 대해 65~78비트 사이의 segmented 주소로 매핑되고, 주어진 프로세서에 대해 physical memory에 최대 60비트를 허용합니다.
Oracle SPARC Architecture 2015는 virtual memory에 64비트를 허용하고, 주어진 프로세서에 대해 physical memory에 40~56비트 사이를 허용합니다.
ARM AArch64 Virtual Memory System Architecture는 virtual memory에 4856비트 사이를 허용하고, 주어진 프로세서에 대해 physical memory에 3256비트 사이를 허용합니다.
DEC Alpha 사양은 최소 43비트의 virtual memory 주소 공간 (8 TB)을 지원하도록 요구하며, 하드웨어는 지원되지 않는 비트가 0인지 확인하고 트랩해야 합니다 (향후 프로세서에서 호환성을 지원하기 위해). Alpha 21064는 43비트의 virtual memory 주소 공간 (8 TB)과 34비트의 physical memory 주소 공간 (16 GB)을 지원했습니다. Alpha 21164는 43비트의 virtual memory 주소 공간 (8 TB)과 40비트의 physical memory 주소 공간 (1 TB)을 지원했습니다. Alpha 21264는 사용자 구성 가능한 43 또는 48비트의 virtual memory 주소 공간 (8 TB 또는 256 TB)과 44비트의 physical memory 주소 공간 (16 TB)을 지원했습니다.
64-bit 애플리케이션
32-bit에서 64-bit 아키텍처로의 변경은 근본적인 변경입니다. 대부분의 operating systems는 새로운 아키텍처를 활용하기 위해 광범위하게 수정되어야 하기 때문입니다. 그 소프트웨어는 실제 메모리 주소 지정 하드웨어를 관리해야 합니다. 다른 소프트웨어도 새로운 기능을 사용하도록 ported되어야 합니다. 구형 32-bit 소프트웨어는 64-bit instruction set이 32-bit instruction set의 상위 집합이라는 이유로 지원될 수 있으므로 64-bit instruction set을 지원하는 프로세서도 32-bit instruction set의 코드를 실행할 수 있거나, 소프트웨어 emulation을 통해, 또는 Intel의 일부 Itanium 프로세서처럼 64-bit 프로세서 내에 32-bit 프로세서 코어의 실제 구현을 통해 지원될 수 있습니다. 이는 32-bit x86 애플리케이션을 실행하기 위해 IA-32 프로세서 코어를 포함했습니다. 이러한 64-bit 아키텍처를 위한 operating system은 일반적으로 32-bit 및 64-bit 애플리케이션을 모두 지원합니다.
이에 대한 한 가지 중요한 예외는 IBM AS/400입니다. 이 소프트웨어는 Technology Independent Machine Interface (TIMI)라는 virtual instruction set architecture (ISA)로 컴파일됩니다. TIMI 코드는 실행되기 전에 저수준 소프트웨어에 의해 native machine code로 변환됩니다. 변환 소프트웨어는 전체 OS 및 모든 소프트웨어를 새 플랫폼으로 이동할 때 다시 작성되어야 하는 모든 것입니다. IBM이 AS/400의 native instruction set을 구형 32/48-bit IMPI에서 새로운 64-bit PowerPC-AS (코드명 Amazon)로 전환했을 때입니다. IMPI instruction set은 32-bit PowerPC와도 상당히 달랐으므로 이 전환은 주어진 instruction set을 32비트에서 64비트로 이동하는 것보다 훨씬 더 컸습니다.
x86-64 아키텍처를 가진 64-bit 하드웨어에서 대부분의 32-bit operating system과 애플리케이션은 호환성 문제 없이 실행될 수 있습니다. 64-bit 아키텍처의 더 큰 주소 공간은 digital video, scientific computing, 대규모 databases와 같은 애플리케이션에서 대규모 데이터 세트로 작업하기 쉽게 만들지만, 32-bit compatibility modes와 비교하여 다른 작업에 대해 더 빠를지 여부에 대해 상당한 논쟁이 있었습니다.
컴파일된 Java 프로그램은 수정 없이 32-bit 또는 64-bit Java virtual machine에서 실행될 수 있습니다.
char, short, int, long, float, double과 같은 모든 내장 타입의 길이와 정밀도, 그리고 배열 인덱스로 사용될 수 있는 타입은 표준에 의해 지정되며 기본 아키텍처에 의존하지 않습니다. 64-bit Java virtual machine에서 실행되는 Java 프로그램은 더 큰 주소 공간에 접근할 수 있습니다.속도는 32-bit 및 64-bit 프로세서를 비교할 때 고려할 유일한 요소가 아닙니다. multi-tasking, stress testing, clustering과 같은 애플리케이션 – high-performance computing (HPC)의 경우 – 적절하게 배포될 때 64-bit 아키텍처에 더 적합할 수 있습니다. 이러한 이유로 64-bit 클러스터는 IBM, HP, Microsoft와 같은 대규모 조직에서 광범위하게 배포되었습니다.
요약:
- 64-bit 프로세서는 64-bit 소프트웨어로 최고의 성능을 발휘합니다.
- 64-bit 프로세서는 backward compatibility를 가질 수 있으며, 이를 통해 32-bit instruction set의 32-bit 버전을 위한 32-bit 애플리케이션 소프트웨어를 실행할 수 있으며, 32-bit instruction set의 32-bit 버전을 위한 32-bit operating system 실행도 지원할 수 있습니다.
- 32-bit 프로세서는 64-bit 소프트웨어와 호환되지 않습니다.
일반적인 오해는 64-bit 아키텍처가 컴퓨터에 4 GB 이상의 random-access memory가 없으면 32-bit 아키텍처보다 나을 것이 없다는 것입니다. 이것이 완전히 사실은 아닙니다:
- 일부 operating system과 특정 하드웨어 구성은 IA-32 시스템의 물리적 메모리 공간을 3 GB로 제한합니다. 3–4 GB 영역의 대부분이 하드웨어 주소 지정을 위해 예약되어 있기 때문입니다. 3 GB barrier를 참조하세요. 64-bit 아키텍처는 4 GB보다 훨씬 더 많은 주소를 지정할 수 있습니다. 그러나 Pentium Pro부터의 IA-32 프로세서는 Physical Address Extension (PAE)을 사용하여 36-bit physical 메모리 주소 공간을 허용하며, 이는 64 GB physical 주소 범위를 제공하며, 이 중 최대 62 GB를 주 메모리로 사용할 수 있습니다. PAE를 지원하는 operating system은 IA-32 프로세서에서도 4 GB의 물리적 메모리로 제한되지 않을 수 있습니다. 그러나 드라이버 및 기타 kernel mode 소프트웨어, 특히 구형 버전은 PAE와 호환되지 않을 수 있습니다. 이것이 32-bit 버전의 Microsoft Windows가 4 GB의 물리적 RAM으로 제한되는 이유로 인용되었습니다. 그러나 이 설명의 타당성은 논쟁의 여지가 있습니다.
- 일부 operating system은 process address space의 일부를 OS 사용을 위해 예약하여 사용자 프로그램을 위한 메모리 매핑에 사용 가능한 총 주소 공간을 효과적으로 줄입니다. 예를 들어 32-bit Windows는 kernel을 위해 총 주소 공간의 1 또는 2 GB (설정에 따라)를 예약하여 사용자 모드에 3 또는 2 GB (각각)의 주소 공간만 남깁니다. 이 한계는 64-bit operating system에서 훨씬 더 높습니다.
- Memory-mapped files는 4 GB를 초과하는 파일이 더 일반화됨에 따라 32-bit 아키텍처에서 구현하기가 점점 더 어려워지고 있습니다. 이러한 대규모 파일은 32-bit 아키텍처에 쉽게 메모리 매핑될 수 없습니다. 파일의 일부만 주소 공간에 매핑될 수 있으며, 메모리 매핑으로 이러한 파일에 접근하려면 필요에 따라 매핑된 부분을 주소 공간으로 교체해야 합니다. 이것은 문제입니다. 메모리 매핑이 OS에 의해 적절하게 구현되면 가장 효율적인 disk-to-memory 방법 중 하나이기 때문입니다.
- encoders, decoders, encryption 소프트웨어와 같은 일부 64-bit 프로그램은 64-bit register로부터 크게 이득을 볼 수 있으며, 3D 그래픽 지향 프로그램과 같은 다른 프로그램의 성능은 32-bit에서 64-bit 환경으로 전환할 때 영향을 받지 않습니다.
C의 예:
이 코드는 먼저 5개의 값을 생성합니다: a, b, c, d, e; 그 다음 루프에 넣습니다. 루프 중에 이 코드는 b의 값을 a의 값으로, c의 값을 b의 값으로, d의 값을 c의 값으로, e의 값을 d의 값으로 변경합니다. 이는 모든 값을 a로 변경하는 것과 같은 효과를 가집니다.
프로세서가 register에 2개 또는 3개의 값만 유지할 수 있다면 변수 d와 e도 처리할 수 있도록 메모리와 register 사이에 일부 값을 이동해야 합니다. 이는 많은 CPU 사이클이 걸리는 프로세스입니다. 모든 값과 변수를 register에 유지할 수 있는 프로세서는 각 반복에 대해 register와 메모리 사이에 데이터를 이동할 필요 없이 루프를 통해 반복할 수 있습니다. 이 동작은 virtual memory와 쉽게 비교할 수 있지만, 모든 효과는 컴파일러에 따라 달라집니다.
64-bit 아키텍처의 주요 단점은 32-bit 아키텍처에 비해 동일한 데이터가 메모리에서 더 많은 공간을 차지한다는 것입니다 (더 긴 포인터 및 가능한 다른 타입, 그리고 alignment padding 때문에). 이는 주어진 프로세스의 메모리 요구 사항을 증가시키고 효율적인 processor cache 사용에 영향을 미칠 수 있습니다. 부분 32-bit 모델을 유지하는 것은 이를 처리하는 한 가지 방법이며 일반적으로 합리적으로 효과적입니다. 예를 들어 z/OS operating system은 이 접근 방식을 취하여 프로그램 코드가 31-bit 주소 공간에 있어야 합니다 (높은 순서 비트는 기본 하드웨어 플랫폼의 주소 계산에 사용되지 않음). 데이터 객체는 선택적으로 64-bit 영역에 있을 수 있습니다. 모든 이러한 애플리케이션이 큰 주소 공간을 필요로 하거나 64-bit 데이터 항목을 조작하는 것은 아니므로 이러한 애플리케이션은 이러한 기능으로부터 이득을 얻지 못합니다.
소프트웨어 가용성
x86 기반 64-bit 시스템은 때때로 32-bit 아키텍처를 위해 작성된 software의 동등물이 부족합니다. Microsoft Windows의 가장 심각한 문제는 구식 하드웨어를 위한 호환되지 않는 device drivers입니다. 대부분의 32-bit 애플리케이션 소프트웨어는 compatibility mode에서 64-bit operating system에서 실행될 수 있으며, 이를 emulation 모드라고도 합니다. 예를 들어 Microsoft WoW64 Technology for IA-64 및 AMD64. 64-bit Windows Native Mode 드라이버 환경은 64-bit NTDLL.DLL 위에서 실행되며, 이는 32-bit Win32 subsystem 코드를 호출할 수 없습니다 (종종 실제 하드웨어 기능이 user mode 소프트웨어에서 에뮬레이트되는 기기 (예: Winprinters)). 대부분의 기기에 대한 64-bit 드라이버는 2007년 초 (Vista x64)까지 사용 가능하지 않았기 때문에 64-bit 버전의 Windows를 사용하는 것은 도전으로 간주되었습니다. 그러나 추세는 이후 64-bit 컴퓨팅으로 이동했으며, 메모리 가격이 하락하고 4 GB 이상의 RAM 사용이 증가함에 따라 더욱 그렇습니다. 대부분의 제조업체는 새 기기에 대해 32-bit 및 64-bit 드라이버를 모두 제공하기 시작했으므로 64-bit 드라이버의 부재는 더 이상 문제가 되지 않았습니다. 64-bit 드라이버는 많은 구형 기기에 대해 제공되지 않았으므로 이러한 기기는 64-bit 시스템에서 사용될 수 없었습니다.
드라이버 호환성은 open-source 드라이버에서는 덜 문제였습니다. 32-bit 드라이버는 64-bit 사용을 위해 수정될 수 있었기 때문입니다. 2007년 초 이전에 만들어진 하드웨어에 대한 지원은 open-source 플랫폼에서 문제가 있었습니다. 사용자 수가 상대적으로 적었기 때문입니다.
64-bit 버전의 Windows는 16-bit 소프트웨어를 실행할 수 없습니다. 그러나 대부분의 32-bit 애플리케이션은 잘 작동합니다. 64-bit 사용자는 16-bit 애플리케이션을 실행하거나 NTVDM의 대안 중 하나를 사용하기 위해 16- 또는 32-bit operating system의 virtual machine을 설치해야 합니다.
Mac OS X 10.4 "Tiger"와 Mac OS X 10.5 "Leopard"는 32-bit kernel만 가지고 있었지만 64-bit 프로세서에서 64-bit user-mode 코드를 실행할 수 있습니다. Mac OS X 10.6 "Snow Leopard"는 32-bit 및 64-bit kernel을 모두 가지고 있었으며, 대부분의 Mac에서 64-bit 프로세서에서도 32-bit kernel을 사용했습니다. 이를 통해 이러한 Mac은 64-bit 프로세스를 지원하면서도 32-bit 기기 드라이버를 지원할 수 있었습니다. 64-bit 드라이버는 아니지만 그에 따른 성능 이점도 없습니다. Mac OS X 10.7 "Lion"은 더 많은 Mac에서 64-bit kernel로 실행되었으며, OS X 10.8 "Mountain Lion" 이후의 macOS 출시는 64-bit kernel만 가지고 있습니다. 64-bit 프로세서가 있는 시스템에서 32-bit 및 64-bit macOS kernel은 모두 32-bit user-mode 코드를 실행할 수 있으며, macOS Mojave (10.14)까지의 모든 macOS 버전은 32-bit 애플리케이션이 사용할 라이브러리의 32-bit 버전을 포함하므로 macOS용 32-bit user-mode 소프트웨어는 이러한 시스템에서 실행됩니다. 32-bit 라이브러리 버전은 Apple에 의해 macOS Catalina (10.15)에서 제거되었습니다.
Linux와 대부분의 다른 Unix-like operating system, 그리고 그들을 위한 C와 C++ toolchains는 많은 해 동안 64-bit 프로세서를 지원했습니다. 이러한 플랫폼을 위한 많은 애플리케이션과 라이브러리는 C와 C++로 작성된 open-source software이므로, 64-bit 안전하면 64-bit 버전으로 컴파일될 수 있습니다. 이 source 기반 배포 모델은 빈번한 출시에 중점을 두고 있어 이러한 operating system을 위한 애플리케이션 소프트웨어의 가용성이 덜 문제가 됩니다.
32-bit 프로그램에서 pointers와 integer와 같은 데이터 타입은 일반적으로 같은 길이를 가집니다. 이것이 64-bit 머신에서 반드시 사실인 것은 아닙니다. C와 C++, Objective-C와 같은 프로그래밍 언어에서 데이터 타입을 혼합하면 32-bit 구현에서는 작동하지만 64-bit 구현에서는 작동하지 않을 수 있습니다.
64-bit 머신의 많은 프로그래밍 환경에서 C 및 C 파생 언어의 경우
int 변수는 여전히 32비트 너비이지만 long integers와 pointers는 64비트 너비입니다. 이들은 "Long, Pointer, 64"의 약자인 LP64 data model을 가지고 있다고 설명됩니다. 다른 모델은 세 가지 데이터 타입이 모두 64비트 너비인 ILP64 data model이며, 심지어 short integers도 64비트 너비인 SILP64 모델도 있습니다. 그러나 대부분의 경우 필요한 수정은 상대적으로 경미하고 직관적이며, 많은 잘 작성된 프로그램은 변경 없이 새 환경을 위해 단순히 다시 컴파일될 수 있습니다. 또 다른 대안은 32-bit 코드와의 호환성을 유지하기 위해 int와 long을 모두 32-bit로 남겨두는 LLP64 모델입니다. LL은 모든 플랫폼 (32-bit 환경 포함)에서 최소 64비트인 long long integer 타입을 나타냅니다.64-bit 프로세서를 사용하지만 ILP32 data model을 사용하는 시스템도 있으며, 64-bit long long integers를 추가합니다. 이는 많은 32-bit 프로세서가 있는 플랫폼에서도 사용됩니다. 이 모델은 코드 크기와 포인터를 포함하는 데이터 구조의 크기를 줄이지만, 훨씬 더 작은 주소 공간의 비용으로 일부 embedded system에 좋은 선택입니다. x86 및 ARM과 같은 instruction set의 경우 64-bit 버전의 instruction set이 32-bit 버전보다 더 많은 register를 가지고 있으므로 공간 페널티 없이 추가 register에 접근할 수 있습니다. 64-bit RISC 머신에서 일반적이며, x86에서 x32 ABI로 탐색되었으며, 최근에 Apple Watch Series 4와 5에서 사용되었습니다.
64-bit 데이터 모델 | short int | int | long int | long long | Pointer, size_t | 샘플 operating system |
|---|---|---|---|---|---|---|
ILP32 | 16 | 32 | 32 | 64 | 32 | Linux 시스템의 x32 및 arm64ilp32 ABIs; MIPS N32 ABI. |
LLP64 | 16 | 32 | 32 | 64 | 64 | |
LP64 | 16 | 32 | 64 | 64 | 64 | |
ILP64 | 16 | 64 | 64 | 64 | 64 | |
SILP64 | 64 | 64 | 64 | 64 | 64 |
오늘날 많은 64-bit 플랫폼은 LP64 모델을 사용합니다 (Solaris, AIX, HP-UX, Linux, macOS, BSD, IBM z/OS 포함). Microsoft Windows는 LLP64 모델을 사용합니다. LP64 모델의 단점은
long을 int에 저장하면 잘린다는 것입니다. 반면에 포인터를 long으로 변환하면 LP64에서 "작동"합니다. LLP64 모델에서는 반대가 사실입니다. 이들은 완전히 표준 준수 코드에 영향을 미치지 않는 문제이지만, 코드는 종종 데이터 타입의 너비에 대한 암묵적 가정으로 작성됩니다. C 코드는 포인터를 정수 객체로 캐스팅할 때 long 대신 (u)intptr_t를 선호해야 합니다.프로그래밍 모델은 주어진 컴파일러에 맞게 선택되며, 여러 개가 동일한 OS에 공존할 수 있습니다. 그러나 OS application programming interface (API)의 주요 모델로 선택된 프로그래밍 모델이 일반적으로 지배합니다.
또 다른 고려 사항은 device drivers에 사용되는 데이터 모델입니다. 드라이버는 대부분의 현대 operating system에서 operating system 코드의 대부분을 구성합니다 (실행 중인 operating system일 때 많은 것이 로드되지 않을 수 있지만). 많은 드라이버는 포인터를 많이 사용하여 데이터를 조작하며, 경우에 따라 direct memory access (DMA)를 위해 지원하는 하드웨어에 특정 크기의 포인터를 로드해야 합니다. 예를 들어 32-bit PCI 기기를 위한 드라이버가 기기에 64-bit 머신의 상위 영역에 데이터를 DMA하도록 요청하는 경우 기기의 DMA register에 맞지 않기 때문에 4 gigabyte 장벽 위의 메모리에서 데이터를 로드하도록 operating system의 요청을 충족할 수 없습니다. 이 문제는 OS가 DMA에 대한 드라이버 요청을 생성할 때 기기의 메모리 제한을 고려하거나 input–output memory management unit (IOMMU)을 사용하여 해결됩니다.
현재 64-bit 아키텍처
2023년 8월 기준으로 프로세서가 제조된 64-bit 아키텍처는 다음을 포함합니다:
- Advanced Micro Devices (AMD)가 Intel의 x86 아키텍처에 만든 64-bit 확장 (나중에 Intel에서 라이선스함); 일반적으로 x86-64, AMD64, 또는 x64라고 불림:
- VIA Technologies의 64-bit 확장으로 VIA Nano 프로세서에서 사용됨
- ARM Holdings의 AArch64 아키텍처
- IBM의 z/Architecture, ESA/390 아키텍처의 64-bit 버전으로 IBM의 IBM Z mainframes에서 사용됨:
- IBM Telum II 프로세서 및 전임자
- Hitachi AP8000E
- SPARC V9 아키텍처:
- Oracle의 M8 및 S7 프로세서 및 전임자
- Fujitsu의 SPARC64 XII 및 SPARC64 XIfx 프로세서 및 전임자
- MIPS Technologies의 MIPS64 아키텍처
- Elbrus 아키텍처:
32비트 아키텍처에서 파생된 64비트 아키텍처의 대부분은 성능 페널티 없이 32-bit 버전을 위해 작성된 코드를 native로 실행할 수 있습니다. 예를 들어 AMD64 및 Intel 64를 가진 프로세서는 전체 속도로 32-bit 애플리케이션을 실행할 수 있습니다. 이러한 종류의 지원은 일반적으로 bi-arch support 또는 더 일반적으로 multi-arch support라고 불립니다.
0
0
댓글
?
아직 댓글이 없습니다.
첫 번째 댓글을 작성해보세요!