mir.pe (일반/밝은 화면)
최근 수정 시각 : 2024-12-21 13:36:36

AMD64


명령어 집합
CISC AMD64 ● x86 ● · M68K · 68xx · Z80 · 8080 · MOS 65xx · VAX
RISC AArch64 ARM · RISC-V ● · MIPS ● · DEC Alpha · POWER PowerPC · CELL-BE
LoongArch · OpenRISC · PA-RISC · SPARC · Blackfin · SuperH · AVR32 AVR
VLIW
EPIC 		E2K · IA-64 · Crusoe

파일:AMD64 로고.svg

1. 개요2. 역사
2.1. 레벨
3. 특징4. 전개5. 시스템 아키텍처
5.1. 제어 레지스터5.2. 메모리
5.2.1. 페이징
6. 명령어 목록7. ABI
7.1. 호출 규약
8. 여담9. 관련 문서

[clearfix]

1. 개요

AMD64는 짐 켈러 주도로 AMD가 1999년에 발표한 x86의 64비트 확장 아키텍처로, 현시점인 2020년대 기준으로 절대다수의 CPU가 채택하고 있는 아키텍처이다. 표준 명칭은 AMD64이지만 x86-64, x64, EM64T, Intel64[1] 등 여러 이름으로도 불린다.

2. 역사

64비트 컴퓨팅 시장을 놓고 인텔과 AMD는 서로 다른 꿈을 꾸고 있었다. 인텔은 x86의 문제점을 알고 있었기 때문에 1994년에 개발을 시작한 IA-64를 통해서 64비트로 단절적 이행을 생각하고 있었고, 이 때문에 아이태니엄 프로세서는 x86 호환성이 없었다. AMD는 x86 구조를 유지한 채 자체적으로 64비트로 확장하기로 결심했고, 1999년 x86-64라는 이름으로 64비트 확장 x86 명령어 셋을 발표했다. x86-64가 탑재되어 출시된 첫 제품은 2003년에 나온 K8 마이크로아키텍처 기반의 슬레지해머 계열 옵테론과 클로우해머 계열 애슬론 64이며, 결국 인텔도 2004년 6월 후기 프레스캇에서 x86-64를 지원하는 방향으로 선회하면서 업계의 사실상 표준으로 자리잡게 되었다.

<rowcolor=#fff> x86 · AMD64 확장 명령어 집합
인텔 주도 확장 명령어
범용 APX
SIMD MMX · SSE SSE2 · SSE3 · SSSE3 · SSE4.1 · SSE4.2 · AVX AVX2 · AVX-512 · AVX10 · AMX
AVX-512: F · CD · DQ · BW · VL · IFMA · VBMI · VBMI2 · VNNI · VAES · GFNI · BITALG
AVX[1]: AVX-VNNI · AVX-IFMA
AVX10: AVX10.1 · AVX10.2
비트 조작 BMI1 · BMI2 · ADX
보안 및 암호 AES-NI · CLMUL · RDRAND · RDSEED · SHA · MPX · SGX · TME · MKTME
가상화 및 기타 VT-x(VMX) · SMX · TSX
AMD 주도 확장 명령어
SIMD 및 비트 연산 3DNow! PREFETCHW · F16C · XOP · FMA FMA4 · FMA3
비트 조작 ABM
보안 및 암호 SME
가상화 및 기타 AMD-V
[1] 512-bit EVEX 인코딩된 AVX-512 명령어의 256-bit VEX 인코딩 버전

2.1. 레벨

파편화를 정리하고 선형적이고 간결한 구별로 만들기 위해 2020년 Red Hat의 Florian Weimer와 오픈수세가 한 제안을 인텔과 AMD가 받아들여 만들어졌다 #.

AMD에서 AMD64를 만들었지만 시장점유율은 인텔이 훨씬 앞섰고, 따라서 제안되는 명령어 채택율도 인텔이 크게 앞서면서 사실상 인텔이 주도해서 만드는 명령어가 되고 있다. AMD는 SSE5 같은 자신만의 명령어 셋이나 컴파일러 개발에 힘 썼지만 x86-64-v4이후 이러한 노력을 접고 인텔에 맞춰 가고 있다. 오히려 인텔이 2020년대 초반부터 중반까지 E코어 이슈로 개인용 CPU들을 AVX-512가 제거된 x86-64-v3을 시장에 내놔서 AMD보다 자사표준에 밀리는 일도 있었다.

CPUID라는 세분화 명령어가 이미 있는데 또 v2, v3, v4 같은 이상한 구별을 해서 컴파일에 복잡성을 키웠다고 리누스 토르발스가 2024년에 대차게 깠다 # 재미있는것은 상술하듯 이 레벨 구분은 리눅스 진영과 오픈소스 진영에서 주도했는데, 리누스 토르발스는 언급에서 '누가했는지 모르겠지만 방귀 같은 생각' 이라며 심하게 욕했다는 점이다. 외국 뉴스에서는 2020년에 만들어질 당시엔 토르발즈가 가만히 있다가 2024년에 x86 자문위원회에 들어가 발언권이 더 커지면서 리눅스 진영과 오픈소스 진영에 쓴소리 한것이라고 추정했다. #

자신의 CPU가 x86-64-v 몇 레벨 확인 하기 위해선 리눅스에선 #이 방법을 윈도우는 # 이 프로그램을 쓰면된다.

3. 특징

90년대를 풍미했던 32비트 기반 주요 명령어 세트가 64비트로 확장되었을 때의 보여줬던 방식들을 무리 없이 잘 따라갔다. 주요 변경점을 살펴보면,

4. 전개

AMD64가 2003년 K8 마이크로아키텍처 기반 슬레지해머 계열의 옵테론, 클로우해머 게열의 애슬론 64로 시장에 도입되어 인기를 끌고 인텔도 2004년 6월 후기 프레스캇부터 지원을 시작한 후 CPU에서는 대부분 AMD64를 지원하게 되면서 AMD64는 빠른 속도로 x86을 이어 시장에서 사실상의 표준의 위치를 점하게 되었다.

다만 운영 체제와 애플리케이션은 CPU 시장의 추세만큼 빠르게 64비트로 전환하지 못 했다. Linux는 애슬론 64가 출시되기 이전인 2001년부터 AMD64를 지원하기 시작했고, 64비트 리눅스 배포판은 상당히 빠르게 출시되었다. 커널과 유저랜드 모두가 오픈소스인 특성상 프로그램의 64비트 지원이 윈도우에 비하면 상당히 빠른 편이었다. 그래서 대용량 데이터를 다룰 필요가 있는 시스템은 64비트 리눅스로 빠르게 전환했다.

반면 윈도우 쪽은 리눅스에 비하면 64비트 전환이 상당히 느렸다. 2005년에 Windows XP x64 에디션이 출시되었으나, 사실상 NT 커널 버전이 다른 Windows Server 2003을 개인용으로 끌어 내린 버전이었기 때문에 별 반향 없이 넘어갔다.[15] 2006년 말의 Windows Vista에서는 제대로 된 AMD64를 지원하였으나, 비스타 자체가 흥행하지 못하였고, 2009년 가을 Windows 7이 성공하고 나서야 윈도우 시장에도 AMD64가 안착하게 된다. 이후 64비트 운영 체제의 점유율 상승은 PC에 들어가는 RAM 용량의 증가세에 의해 좌우되었다. 2010년대 이전부터 이미 32비트 운영 체제의 메모리 지원 용량을 초월해버렸기 때문.

윈도우 쪽 프로그램은 소스 코드가 공개되지 않는 경우가 대부분이고, 따라서 64비트 윈도우에서도 32비트 바이너리 코드를 돌려야 할 필요성이 많았다. 그래서 32비트 윈도우에 비해서 64비트 윈도우는 32비트 라이브러리까지 다 포함해야 했기 때문에 디스크 공간도 더 많이 필요했고, 프로그램 개발자 입장에서도 32비트 바이너리가 그대로 도는 상황에서 64비트 컴퓨팅으로 확실한 이득을 얻을 수 있는지 확신이 어려웠기 때문에 64비트 전환이 지지부진했다. 64비트 웹 브라우저나 탐색기에서는 32비트 플러그인을 돌릴 수 없었기 때문에 Internet Explorer는 32비트, 64비트 모두 탑재하되 기본적으로는 32비트가 실행되도록 되어 있었고, 탐색기도 셸 확장 때문에 Windows Vista까지는 32비트가 기본값이었으나 Windows 7 출시 직전에 64비트가 기본값이 되었다. IE는 2015년 Windows 10이 IE를 버리고 새로운 웹 브라우저인 엣지를 탑재하면서 64비트로 넘어가게 된다.

하지만 리눅스 쪽은 커널과 프로그램의 소스 코드가 대부분 공개되어 있기 때문에 단순히 다시 컴파일하는 것 만으로 64비트 지원을 도입하기 상당히 쉬웠다. 덕분에 리눅스 세계는 64비트 웹 브라우저가 일찍부터 상용화되어 있었고, 64비트 웹 브라우저 플러그인에 대한 수요가 있었다. 대표적으로 어도비 플래시 플레이어도 2011년에 64비트 플러그인을 모든 플랫폼으로 정식 출시했지만, 그보다 훨씬 이전인 2008년부터 리눅스 전용 알파 버전을 출시해 왔다. macOS 쪽은 애플의 가차 없는 과거 호환성 던져 버리기 덕분에 64비트 도입이 적극적이었다. 애플이 컴퓨터에 사용했던 32비트 인텔 프로세서가 인텔 코어 시리즈밖에 없었고, 애플 TV 1세대에만 펜티엄 M을 잠깐 사용했기 때문에 OS X 10.4와 10.5만 32비트 커널을 사용했고, 10.6 이후부터는 64비트 커널이 기본값이 되었다. 10.15부터는 완전히 32비트 지원이 제거되어 이제 더이상 32비트 애플리케이션은 실행되지 않는다.

게임 분야는 2013년부터 일부 고사양 게임들은 처음부터 64비트 운영 체제에서만 실행할 수 있도록 제작되고 있다. 대형 게임은 그래픽 데이터가 매우 크기 때문에 메모리 사용량이 커서 기존 3GB 정도의 메모리는 절대 부족하기 때문이다. 현재 출시되고 있는 대부분의 대형 게임(특히 사양이 높은 FPS 게임들)은 64비트 운영 체제만 지원하고 있다. 오버워치와 배틀그라운드도 Windows 7 이상, 64비트[16]에서만 실행할 수 있다.

여담으로 인텔의 경우 코어2 계열까지는 64비트 성능이 동세대 AMD 프로세서에 비해 밀리는 감이 있었다. 제대로 성능을 내기 시작한 시점은 네할렘 기반인 코어 i 시리즈(및 이를 기반으로 하는 펜티엄 및 셀러론)부터. 애초에 AMD의 기술인데다 당시 초창기라 인텔이 해당 기술에 적응하지 못한 결과가 아닌가 싶다. 물론 이때는 32비트가 주력이라 이 당시에는 큰 문제가 없었다.

5. 시스템 아키텍처

5.1. 제어 레지스터

5.2. 메모리

5.2.1. 페이징

페이징 모드 CR0.PG CR4.PAE IA32_EFER.LME CR4.LA57 가상 주소 크기 물리 주소 크기 페이지 크기 XD 지원 PCID 지원
없음 0 - - - (32) 32 - X X
32-bit 1 0 0 - 32 ~40 4 KB
4 MB 		X X
PAE 1 1 0 - 32 ~52 4 KB
2 MB 		O X
4-level 1 1 1 0 48 ~52 4 KB
2 MB
1 GB 		O O
5-level 1 1 1 1 57 ~52 4 KB
2 MB
1 GB 		O O

6. 명령어 목록

파일:상세 내용 아이콘.svg   자세한 내용은 AMD64/명령어 목록 문서
를
의 번 문단을
의 부분을
참고하십시오.

7. ABI

7.1. 호출 규약

아키텍처 호출 규약 인자 (parameters) 반환값
(return value) 		Caller-saved
Registers 		Callee-saved
Registers 		Stack
Cleanup 		비고
레지스터 스택 방향
64-bit Microsoft (Windows 환경)
x64 RCX, RDX, R8, R9
XMM0-3
vectorcall RCX, RDX, R8, R9
XMM0-5
System V AMD64 (Linux, MacOS 등 Unix 환경)
sysv RDI, RSI, RCX, RDX,
R8, R9, XMM0-7 		EAX(, EDX)
XMM0-1
ST(0), ST(1)[long_double]
32-bit Microsoft (Windows 환경)
cdecl (스택만 사용) High-to-Low EAX(, EDX)
[EAX][18]
ST(0)[x87] 		EAX, ECX, EDX EBX, ESI, EDI
ESP, EBP 		Caller
stdcall Callee
fastcall ECX, EDX Callee
thiscall (C++) ECX Callee [20]
vectorcall[SSE2] ECX, EDX, XMM0-5[22] EAX(, EDX)
[EAX]
XMM0(~XMM3)[23] 		Callee
GNU (Linux 환경)
cdecl (스택만 사용) High-to-Low EAX(, EDX)
[EAX][24]
ST(0)[x87] 		EAX, ECX, EDX EBX, ESI, EDI
ESP, EBP 		Caller
thiscall (C++) [26]

8. 여담

x86-64, AMD64, Intel64, 얌힐, IA-32e, EM64T, x64 등의 여러 이름으로 불리게 된 이유는 AMD64를 둘러싼 인텔과 AMD 두 회사간의 알력의 결과이다.

처음 AMD가 x86-64라는 이름으로 x86의 64비트 확장 계획을 1999년에 발표했을 때, 인텔의 공식 입장은 IA-32는 별도의 64비트화 계획이 없고, IA-64가 인텔의 차세대 64비트라는 것이었다. 그러나 이러한 결정으로 인해 후술하듯이 인텔 내부에서 희대의 내부 음모 사건이 일어나는 계기가 되었는데, 당시 프레스캇의 기초 설계를 진행하고 있던 인텔 오레건 설계 팀에서 x86-64를 적용한 설계를 얌힐이라는 코드명 아래 비밀리에 시작했다. 그런데 흥미로운 것은 회장과 경영진에게도 비밀로 진행했다는 것이다.

이후 2003년에 x86-64 기반의 옵테론과 애슬론 64가 출시되어 시장에서 큰 인기를 얻게 되면서 인텔의 신형 프레스캇에 x86-64가 이미 포함되었다는 루머가 꾸준히 올라오게 된다. 이것이 이른바 얌힐 의혹으로 당시 내로라 하는 벤치마크 사이트들이 얌힐의 다이 사진까지 분석해가면서 관련 의혹을 제기했으나, 인텔은 이를 꾸준히 부인하였다.

그리고 2004년 6월 드디어 x86-64를 지원하는 후기 프레스캇이 시장에 데뷔하면서 기존에 얌힐로 알려져 있던 인텔판 x86-64를 대외적으로 발표하게 되는데, 이것을 x86-64가 아닌 IA-32e라는 이름으로 발표하는 실수를 다시 한 번 저지르게 된다. 인텔의 작명 의도는 x86-64가 단순히 IA-32를 약간 확장한 것에 불과하니까 IA-32e일 뿐[27]이라는 것이었으나, 문제는 이렇게 발표해 놓고 보니 AMD는 같은 기술을 먼저 개발해서 64비트 홍보를 적극적으로 이용하고 있는데 정작 그에 대응해서 같은 기술을 사용하게 된 프레스캇이 64비트를 지원한다는 사실이 가려져버리면서 제품 경쟁력을 스스로 깎아먹는 사태가 벌어지고 만 것.

이런 애매한 문제가 있기에 다시 Extended Memory 64-bit Tech, 줄여서 EM64T라는 이름을 붙였다. 하지만 이러한 일련의 작명 실책들의 배경에는 인텔이 64비트 명령어 셋의 적자(嫡子)는 여전히 IA-64임을 드러내려는 의도가 있기에 저런 어중간한 표현을 한 것이다. 그러나 인텔이 IA-64 기반으로 만든 아이태니엄 시리즈 자체가 흑역사가 되면서 이러한 시도는 전부 의미가 없게 되었다.

파일:intel64.png
AMD 역시 애슬론 64을 출시한 이후 그동안의 중립적인 명칭이었던 x86-64를 AMD64라는 이름으로 바꾸면서 자사의 특허권과 기술을 강조했다. 인텔은 그게 못마땅했는지 자사 프로세서에 사용된 x86-64 호환 기술의 명칭을 EM64T에서 Intel64로 바꾸었지만, 당연히 타사 기준엔 그런 게 없기에 Windows를 포함한 64비트 기반 프로그램에서는 인텔의 x64 기반 프로세서 아키텍처 식별자를 AMD64로 인식한다.

결국 이러한 명칭 싸움의 부작용으로 인해 AMD64를 인텔이 개발한 명령어 셋으로 오해하는 경우조차도 발생하고 있다. 일부 PC 정비사 서적에서 인텔 EM64T(이하 Intel64)를 인텔에서 개발한 64비트 아키텍처라고 설명한 부분이 있는데, 이는 모르는 사람이 볼 때 "인텔에서 독자적으로 개발한 기술"로 오해할 수 있다. 설명한 내용도 그런 식으로 되어있었다. 그런데 EM64T는 위에 서술된 것과 같이 AMD의 x86-64를 크로스 라이선스를 통해 도입한 명령어 셋이다. 추가로 이 서적들의 Intel64 설명 부분에 AMD 및 크로스 라이선스 관련 내용은 일절 없었다.

또한 이러한 명칭 싸움은 일반인들은 물론 컴덕들에게도 혼동을 일으키는 경우가 흔하다. 대표적으로 난 인텔 CPU 쓰는데, 왜 AMD64가 뜨냐?와 같은 질문을 흔히 볼 수 있다. 마이크로소프트에서는 AMD64보다는 x64라는 명칭을 많이 쓰지만, Linux를 다루는 사람들은 AMD64라는 명칭을 아주 흔하게 볼 수 있다.

다만, 이후 인텔이 루머상으로만 알려졌던 "AMD와의 협력"이 2018년에 새로 등장할 인텔 CPU 라인업을 통해 수면위로 떠오르면서 인텔과 AMD 간에 이런 아키텍처 명칭상에서의 껄끄러운 부분은 어느 정도 정리될 가능성이 있었다.[28] 하지만 AMD의 라이젠이 성공을 이루었고, 인텔에게는 CPU 게이트가 터져버린 이후 인텔의 CPU 개발이 지지부진해지면서 AMD와의 협력도 부진한 상태이며, 명칭 문제 따위는 신경 쓸 여유조차 없어진 상태에 이르렀다.

9. 관련 문서


[1] 이 명칭은 인텔만 쓴다. [2] 단적으로 AArch64는 범용 레지스터가 31개이다. [3] [[https://docs.microsoft.com/ko-kr/cpp/cpp/cdecl?view=vs-2019|ARM 및 x64 프로세서에서 [4] 부동소수점 파라미터가 있을 경우 전방 8개 [5] System V AMD64 ABI [6] AMD64 Architecture Programmer’s Manual: Volumes 1-5 | 40332 § 11.4.1 SSE Execution Unit State [7] AMD64 Architecture Programmer’s Manual: Volumes 1-5 | 40332 § 11.4.2 MMX Execution Unit State [8] AMD64 Architecture Programmer’s Manual: Volumes 1-5 | 40332 § 4.6.1.1 Move [9] 스택 구조를 사용하여 레지스터 구조에 비해 추가적인 fxch, fpop, fmov 등의 명령어가 필요하다. 추가적으로 일부 연산의 결과가 IEEE 표준에 규정된 것과 다른 문제가 있다. # [10] AMD64 Architecture Programmer’s Manual: Volumes 1-5 | 40332 § 6.1.3 Compatibility [11] AMD64 Architecture Programmer’s Manual: Volumes 1-5 | 40332 § 5.1 Page Translation Overview & § 2.2.1 Memory Addressing [12] REX Prefix라고 부른다. 0b0100WRXB 형태로 인코딩되며 W는 피연산자의 크기, R, X, B는 레지스터 번호를 확장하는 데 사용된다. [13] AMD64 Architecture Programmer’s Manual, Volume 2: System Programming | 24593 § 2.5.10 Invalid Instructions [14] AAA, AAD, AAM, AAS, BOUND, CALL (far), DAA, DAZ, INTO, JMP (far), LDS, LES, POP DS, POP ES, POP SS, POPA, POPAD, PUSH CS, PUSH DS, PUSH ES, PUSH SS, PUSHA, PUSHAD, SALC, SYSENTER, SYSEXIT, APRL, DEC, INC [15] Windows XP x64 에디션은 영문판과 일본어판만 존재하며, 한글 등의 다른 언어는 영문판에다 언어팩을 설치해야 한다. 게다가 Windows Server 2003 기반이라 서비스 팩은 2밖에 없으며 호환성도 매우 나쁘다. [16] 오버워치의 경우 초창기에는 Windows Vista 64비트도 지원했다. [long_double] 80-bit long double 부동소수점 한정 [18] 반환 자료형의 크기가 큰 경우 스택에 공간을 할당하여 값을 저장하고 그 포인터를 EAX 레지스터에 반환함 [x87] float, double [20] C++ 클래스의 static이 아닌 멤버 함수에 사용됨. 함수의 첫 번째 인자는 this 포인터로, ECX 레지스터를 통해 전달되고 나머지 인자는 스택을 통해 전달됨. [SSE2] SSE2 또는 그 이상 지원되는 경우만 사용 가능 [22] 부동소수점(float, double) 또는 SIMD를 포함하는 '벡터' 인자 [23] 부동소수점(float, double) 또는 SIMD 등 벡터 값. 나머지 자료형의 경우 fastcall과 동일 [24] 반환 자료형의 크기가 큰 경우 스택에 공간을 할당하여 값을 저장하고 그 포인터를 EAX 레지스터에 반환함 [x87] [26] C++ 클래스의 static이 아닌 멤버 함수에 사용됨. 함수의 첫 번째 인자는 this 포인터로, 다른 인자와 마찬가지로 스택을 통해 전달됨 [27] 볼드 처리된 부분은 실제로 그렇다는 게 아니라 인텔의 의도가 그렇다는 것이다. 확장된 것은 어찌됐든 맞는 말이긴 한데 약간 확장한 건 절대 아니기에 거짓말은 하지 않는다 수준의 눈 가리고 아웅이다. 저런 식이면 기존 인텔의 16비트 확장, 32비트 확장 CPU 모두 현실은 8비트, 16비트 CPU라는 게 된다. [28] 이 두 회사가 인텔의 CPU+AMD의 GPU 형태로 협력한 이유도 간단하다. NVIDIA- ARM- 퀄컴이라는 삼각동맹이 성립되었는데, ARM의 CPU + NVIDIA의 GPU + 퀄컴의 통신 모듈의 조합으로 안드로이드 태블릿 및 크롬북 제품을 구글에 공급하는 쪽으로 가고 있기 때문이다. 즉, 기존의 x86 vs PowerPC로 대표되는 CPU 아키텍처 싸움이 90년대 말 x86의 승리로 끝난 후 20년만에 AMD64 vs ARM이라는 새로운 형태의 싸움으로 일어난 것이다.

분류