최근 수정 시각 : 2024-10-18 16:47:59

AMD64

Intel64에서 넘어옴

명령어 집합
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. 레벨

AMD에서 AMD64를 만들었지만 시장점유율은 인텔이 훨씬 앞섰고, 따라서 제안되는 명령어 채택율도 인텔이 크게 앞서면서 사실상 인텔이 주도해서 만드는 명령어가 되고 있다. AMD는 SSE5 같은 자신만의 명령어 셋이나 컴파일러 개발에 힘 썼지만 x86-64-v4이후 이러한 노력을 접고 인텔에 맞춰 가고 있다. 오히려 인텔이 2020년대 초반부터 중반까지 E코어 이슈로 개인용 CPU들을 AVX-512가 제거된 x86-64-v3을 시장에 내놔서 AMD보다 자사표준에 밀리는 일도 있었다.
  • AMD64(=x86-64-v1) : CMOV, CX8, FPU, FXSR, MMX, OSFXSR, SCE, SSE, SSE2 명령어를 사용한다. 최초의 AMD64
  • x86-64-v2 : CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3, SSE4_1, SSE4_2, SSSE3 2024년들어서 레드햇이나 윈도우 11 24H2 등 여러운영체제나 크로미움 등 응용프로그램들이 최소사항으로 요구하고 있다.
  • x86-64-v3 : AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT, MOVBE, OSXSAVE
  • x86-64-v4 : AVX512F, AVX512BW, AVX512CD, AVX512DQ, AVX512VL

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

3. 특징

90년대를 풍미했던 32비트 기반 주요 명령어 세트가 64비트로 확장되었을 때의 보여줬던 방식들을 무리 없이 잘 따라갔다. 주요 변경점을 살펴보면,
  • 주요 레지스터 크기가 32비트에서 64비트로 확장되었다. 일반적으로 64비트 CPU라고 하면 레지스터의 크기가 64비트라는 말이다.
  • x86-32의 기존 8개 레지스터인 EAX, EBX, ECX, EDX, ESP, EBP, ESI, EDI는 특수 기능이 할당되어 있었기 때문에, 전용과 범용 레지스터 사이의 기능을 가지고 있었다. x86-64에는 R8-R15 레지스터 8개가 추가되어 범용 레지스터가 16개가 되었다. ARM 등 다른 아키텍처에 비하면 레지스터 수가 부족하지만[2], x86의 고질적인 레지스터 부족이 크게 완화되었다. 여담으로, 사용 가능한 레지스터의 개수가 확장되면서 권장 호출규약도 변경되었으며, MS Windows의 경우 cdecl을 설정하더라도 무시되고[3]cdecl 는 허용 되지만 일반적으로 컴파일러에서 무시 됩니다.]] ] 전방 4개의 파라미터가 레지스터로 전달된다. Unix 계열 운영 체제는 전방 6개[4]의 파라미터가 레지스터로 전달된다.[5] 따라서 개발자가 특별히 손대지 않아도 기존 x86에 비해 함수 콜의 성능이 향상되었다. 다만 이건 AMD64의 특징은 아니다. 콜링 컨벤션은 소프트웨어 레벨의 규약이지 아키텍처의 규약이 아니기 때문.
  • SSE2가 기본으로 편입되었으며 XMM 레지스터 숫자가 XMM0-XMM7 8개에서 XMM0-XMM15 16개로 확대되었다.[6]
  • MMX는 호환성 유지 목적으로만 사용되며 MMX가 사용하던 64비트 레지스터인 MM레지스터는 8개 그대로 변경이 없다.[7] 또한 MMX의 경우 전용 레지스터가 없이 x87 레지스터를 공유해서 사용하기에 구조적 문제가 있었으나 억지로 레거시 MMX를 쓰지 않는 한 SSE 레지스터의 절반을 사용하는 방법으로 사용하는 것이 가능하기 때문에 매번 emms를 호출할 필요가 없다. 예를 들어 MOVD MM r32은 MOVDQ2Q XMM r32가 되는 식이다. [8]
  • MMX와 마찬가지로 기존 x87 레지스터는 그대로 유지하였다. x87 FPU는 구조적 문제[9]로 인해 x86의 CISC 명령어 세트와 함께 x86의 성능 향상에 발목을 잡는 존재였고, 인텔과 AMD 모두 SSE 명령어 세트로 대체하려는 상황이었으므로 명령어 하위 호환성만을 유지하면서 더 이상의 확장을 중단한 이러한 결정은 타당하였다. 이와 함께 SSE, SSE2가 아키텍처의 기본 명령으로 편입되었다. AMD64에서 모든 부동소수점 연산은 SSE를 사용하여서 연산한다. 예를 들어 부동 소숫점 덧셈 시 fld *ptr; fadd *ptr와 같은 형은 스택 기반 연산은 더이상 사용되지 않고 addss xmm, xmm과 같이 SSE를 사용하게 된다. AMD64 환경에서도 x87명령어 또한 지원하긴 하나 어디까지나 레거시 호환성 목적으로만 사용된다.[10]
  • 가상 메모리 공간은 48비트(256TiB), 물리 메모리 공간은 40비트(1TiB)로 확장되었다. 프로그램 카운터가 64비트임에도 불구하고 메모리공간에 제약을 두는 이유는 메모리 포인터 숫자가 클 경우 페이지 테이블의 오버헤드가 커지기 때문에 굳이 너무 값을 높게 잡을 필요가 없기 때문이다. AMD64가 처음 등장할 당시에는 48/40비트였고 1TB라는 메모리는 매우 큰 용량이었으나 2021년 표준은 가상 64비트(16EiB), 물리 52비트(4PiB)로 확장되었다. [11]
  • 메모리 할당 방식도 바뀌었는데 커널 영역은 메모리 주소 기준으로 맨 끝부분에, 사용자 영역은 처음 부분에 배치하고 점차 중앙으로 갉아먹어가는 구조를 사용한다.
  • 레거시 모드와 롱 모드를 제공한다. 레거시 모드에서는 IA-32와 완전한 호환성을 유지하였으며, 실제 모드와 보호 모드를 지원한다. 64비트 운영 체제에서 활성화 가능한 롱 모드에서는 IA-32의 보호 모드까지 지원하며 실제 모드는 지원하지 않는다. 실제 모드는 MS-DOS 시절에 쓰이던 x86 CPU 모드였고, 이 기능이 꼭 필요한 경우라면 32비트 운영 체제로 레거시 모드를 사용하면 되었기 때문에 롱 모드에서 지원하지 않게 만들었다. 가상 8086 모드는 AMD64 CPU들이 등장한 2003년에는 지원하지 않았으나, 2005년 인텔 VT-x를 시작으로 2006년 AMD의 SVM(現 AMD-V) 같은 가상화 기술로 지원하고 있다.
  • 64비트 확장 명령어들은 명령어 앞에 1바이트의 접두사[12]가 붙는 것으로 구분되었다. 이럴 경우 64비트 모드의 코드에서 32비트를 다루기 위한 명령어를 아무런 변경 없이 그대로 쓰면서 접두사에 의해 유발되는 코드 길이 증가를 억제할 수 있게 된다.
  • NX bit가 추가되었다. 이는 메모리 안정성과 보안성 향상을 위한 기능으로 특히 버퍼 오버런 공격에 대한 취약성을 개선하기 위한 것으로, 2012년 가을에 출시된 Windows 8부터는 이 기능이 필수로 요구되기 시작했다. 인텔 CPU에서는 XD bit라는 이름으로 사용하고 있다.
  • 16/32비트 환경에서 사용되던 명령어들의 일부가 삭제되었고 일부는 다른 기능으로 대체되었다. (DEC/INC -> REX Prefix) [13] [14]
  • 여기에서 명령어 세트의 모습을 볼 수 있다.

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. 제어 레지스터

  • CR0:
  • CR2: 페이지 폴트가 발생한 가상 메모리 주소를 저장하는 레지스터이다.
  • CR3: 가상 메모리(페이징)에 사용되는 제어 레지스터이다. 최상위 페이지 테이블(64비트의 경우 PML4, 5단계 페이징을 사용하는 경우 PML5)의 물리 메모리 주소 및 PCD, PWT 플래그를 포함한다.
  • CR4

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이라는 새로운 형태의 싸움으로 일어난 것이다.

분류