AMD64

 



[image]
1. 개요
2. 역사
3. 특징
4. 전개
5. 명칭에 대한 뒷이야기
6. 관련 문서

[clearfix]

1. 개요

AMD64는 AMD가 1999년에 발표한 x86의 64비트 확장 아키텍처이다. 컴퓨터 CPU라 하면 떠오르는 제품의 대부분이 채택하고 있는 아키텍쳐이다. 표준 명칭은 AMD64이나, x86-64, x64, EM64T, Intel64라고도 불린다.

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를 지원하는 방향으로 선회하면서 업계의 사실상 표준으로 자리잡게 되었다.

3. 특징

90년대를 풍미했던 32비트 기반 주요 명령어 세트가 64비트로 확장되었을 때의 보여줬던 방식들을 무리 없이 잘 따라갔다. 주요 변경점을 살펴보면,
  • 주요 레지스터 크기가 32비트에서 64비트로 확장되었다. 일반적으로 64비트 CPU라고 하면 레지스터의 크기가 64비트라는 말이다.
  • x86의 기존 8개 레지스터인 EAX, EBX, ECX, EDX, ESP, EBP, ESI, EDI는 특수 기능이 할당되어 있었기 때문에, 전용과 범용 레지스터 사이의 기능을 가지고 있었다. x86-64에는 R8-R15 레지스터 8개가 추가되어 범용 레지스터가 16개가 되었다. ARM 등 다른 아키텍처에 비하면 레지스터 수가 부족하지만, x86의 고질적인 레지스터 부족이 크게 완화되었다. 여담으로, 사용 가능한 레지스터의 갯수가 확장되면서 권장 호출규약도 변경되었으며, MS Windows의 경우 cdecl을 설정하더라도 무시되고[* [[https://docs.microsoft.com/ko-kr/cpp/cpp/cdecl?view=vs-2019|ARM 및 x64 프로세서에서 cdecl 는 허용 되지만 일반적으로 컴파일러에서 무시 됩니다.]] ] 전방 4개의 파라미터가 레지스터로 전달된다. Unix 계열 OS는 전방 6개[1]의 파라미터가 레지스터로 전달된다.[2] 따라서 개발자가 특별히 손대지 않아도 기존 x86에 비해 함수 콜의 성능이 향상되었다. 다만 이건 AMD64의 특징은 아니다. 콜링 컨벤션은 소프트웨어 레벨의 규약이지 아키텍쳐의 규약이 아니기 때문.
  • SSE 레지스터 숫자가 XMM0-XMM7 8개에서 XMM0-XMM15 16개로 확대되었다.
  • MMX는 호환성 유지 목적으로만 사용되며 MMX가 사용하던 레지스터인 
    MM
    레지스터는 그대로 8개로 변경이 없다. 다만 MMX 코드의 경우 IA-32 환경에서 x87 레지스터를 공유해서 사용하던것에 비해 SSE의 XMM레지스터의 절반을 사용하는 구조로 동작하게 되기 때문에 x87을 사용하기 위해 
    emms
    를 호출할 필요가 없다. 예를 들어 
    MOVD MM r32
    은 
    MOVDQ2Q XMM r32
    가 되는 식이다.
  • 기존 x87 레지스터는 그대로 유지하였다. x87 구조는 구조적 문제로 인해 x86의 CISC 명령어 세트와 함께 x86의 성능 향상에 발목을 잡는 존재였고, 인텔과 AMD 모두 SSE 명령어 세트로 대체하려는 상황이었으므로 명령어 하위 호환성만을 유지하면서 더 이상의 확장을 중단한 이러한 결정은 타당하였다. 이와 함께 SSE, SSE2가 아키텍처의 기본 명령으로 편입되었다.
  • 가상 메모리 공간은 48비트(256TB), 물리 메모리 공간은 40비트(1TB)로 확장되었다. 프로그램 카운터가 64비트임에도 불구하고 메모리공간에 제약을 두는 이유는 메모리 포인터 숫자가 클 경우 페이지 테이블의 오버헤드가 커지기 때문에 굳이 너무 값을 높게 잡을 필요가 없기 때문이다. 사실 아직까지는 메모리를 1테라까지나 갖춰야 할 필요성이 없기도 하고.
  • 메모리 할당 방식도 바뀌었는데 커널 영역은 메모리 주소 기준으로 맨 끝부분에, 사용자 영역은 처음 부분에 배치하고 점차 중앙으로 갉아먹어가는 구조를 사용한다.
  • 레거시 모드와 롱 모드를 제공하였다. 레거시 모드에서는 IA-32와 완전한 호환성을 유지하였으며 64비트 OS에서 활성화 가능한 롱 모드에서는 IA-32의 프로텍티드 모드까지 호환성을 가지게 되었다. x86 리얼 모드나 가상 x86 모드는 포기하게 되었다. x86 리얼 모드나 가상 x86 모드는 32비트 OS에서 16비트 DOS 시절의 앱들을 지원하기 위한 모드였고, 2000년 초에 NT 커널 기반으로 출시된 Windows 2000과 그 이후로는 사실상 쓰는 앱이 없던 상황이기 때문에 굳이 지원할 필요가 없었다. 두 모드가 꼭 필요한 경우라면 32비트 OS에서 레거시 모드를 사용하면 되었다.
  • 64비트 확장 명령어들은 명령어 앞에 1바이트의 접두사가 붙는 것으로 구분되었다. 이럴 경우 64비트 모드의 코드에서 32비트를 다루기 위한 명령어를 아무런 변경 없이 그대로 쓰면서 접두사에 의해 유발되는 코드 길이 증가를 억제할 수 있게 된다.
  • NX bit가 추가되었다. 이는 메모리 안정성과 보안성 향상을 위한 기능으로 특히 버퍼 오버런 공격에 대한 취약성을 개선하기 위한 것으로, 2012년 가을에 출시된 Windows 8부터는 이 기능이 필수로 요구되기 시작했다. 인텔 CPU에서는 XD bit라는 이름으로 사용하고 있다.
  • 여기에서 명령어 세트의 모습을 볼 수 있다.

4. 전개

AMD64가 2003년 K8 마이크로아키텍처 기반 슬레지해머 계열의 옵테론, 클로우해머 게열의 애슬론 64로 시장에 도입되어 인기를 끌고 인텔도 2004년 6월 후기 프레스캇부터 지원을 시작한 후 CPU에서는 대부분 AMD64를 지원하게 되면서 AMD64는 빠른 속도로 x86을 이어 시장에서 사실상의 표준의 위치를 점하게 되었다.
다만 OS와 애플리케이션은 CPU 시장의 추세만큼 빠르게 64비트로 전환하지 못 했다. 리눅스는 애슬론 64가 출시되기 이전인 2001년부터 AMD64를 지원하기 시작했고, 64비트 리눅스 배포판은 상당히 빠르게 출시되었다. 커널과 유저랜드 모두가 오픈소스인 특성상 프로그램의 64비트 지원이 윈도우에 비하면 상당히 빠른 편이었다. 그래서 대용량 데이터를 다룰 필요가 있는 시스템은 64비트 리눅스로 빠르게 전환했다.
반면 윈도우 쪽은 리눅스에 비하면 64비트 전환이 상당히 느렸다. 2005년에 Windows XP x64 에디션이 출시되었으나, 사실상 NT 커널 버전이 다른 Windows Server 2003을 개인용으로 끌어 내린 버전이었기 때문에 별 반향 없이 넘어갔다.[3] 2006년 말의 Windows Vista에서는 제대로 된 AMD64를 지원하였으나, 비스타 자체가 흥행하지 못하였고, 2009년 가을 Windows 7이 성공하고 나서야 윈도우 시장에도 AMD64가 안착하게 된다. 이후 64비트 OS의 점유율 상승은 PC에 들어가는 RAM 용량의 증가세에 의해 좌우되었다. 2010년대 이전부터 이미 32비트 OS의 메모리 지원 용량을 초월해버렸기 때문.
윈도우 쪽 프로그램은 소스 코드가 공개되지 않는 경우가 대부분이고, 따라서 64비트 윈도우에서도 32비트 바이너리 코드를 돌려야 할 필요성이 많았다. 그래서 32비트 윈도우에 비해서 64비트 윈도우는 32비트 라이브러리까지 다 포함해야 했기 때문에 디스크 공간도 더 많이 필요했고, 프로그램 개발자 입장에서도 32비트 바이너리가 그대로 도는 상황에서 64비트 컴퓨팅으로 확실한 이득을 얻을 수 있는지 확신이 어려웠기 때문에 64비트 전환이 지지부진했다. 64비트 웹 브라우저나 탐색기에서는 32비트 플러그인을 돌릴 수 없었기 때문에 인터넷 익스플로러는 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비트 OS에서만 실행할 수 있도록 제작되고 있다. AAA급 게임은 그래픽 비중이 높아 메모리 사용량이 커서 기존 3GB 정도의 RAM 정도로는 절대적으로 부족하기 때문이다. 2016년 현재 출시되고 있는 대부분의 AAA급 게임(특히 사양이 높은 FPS 게임들)은 64비트 OS만 지원하고 있다. 오버워치와 배틀그라운드도 Windows 7 이상, 64비트[4]에서만 실행 가능하다.
여담으로 인텔의 경우 코어2 계열까지는 64비트 성능이 동세대 AMD 프로세서에 비해 밀리는 감이 있었다. 제대로 성능을 내기 시작한 시점은 네할렘 기반인 코어 i 시리즈(및 이를 기반으로 하는 펜티엄 및 셀러론)부터. 애초에 AMD의 기술인데다 당시 초창기라 인텔이 해당 기술에 적응하지 못한 결과가 아닌가 싶다. 물론 이때는 32비트가 주력이라 이 당시에는 큰 문제가 없었다.

5. 명칭에 대한 뒷이야기

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'''일 뿐[5]이라는 것이었으나, 문제는 이렇게 발표해 놓고 보니 AMD는 같은 기술을 먼저 개발해서 64비트 홍보를 적극적으로 이용하고 있는데 정작 그에 대응해서 같은 기술을 사용하게 된 프레스캇이 '''64비트를 지원한다는 사실이 가려져버리면서''' 제품 경쟁력을 스스로 깎아먹는 사태가 벌어지고 만 것.
이런 애매한 문제가 있기에 다시 '''E'''xtended '''M'''emory '''64'''-bit '''T'''ech, 줄여서 EM64T라는 이름을 붙였다. 하지만 이러한 일련의 작명 실책들의 배경에는 인텔이 '''64비트 명령어 셋의 적자(嫡子)는 여전히 IA-64'''임을 드러내려는 의도가 있기에 저런 어중간한 표현을 한 것이다. 그러나 인텔이 IA-64 기반으로 만든 아이태니엄 시리즈 자체가 흑역사가 되면서 이러한 시도는 전부 의미가 없게 되었다.
[image]
AMD 역시 애슬론 64을 출시한 이후 그동안의 중립적인 명칭이었던 x86-64를 '''AMD'''64라는 이름으로 바꾸면서 자사의 특허권과 기술을 강조했다. 인텔은 그게 못마땅했는지 자사 프로세서에 사용된 x86-64 호환 기술의 명칭을 EM64T에서 '''Intel'''64로 바꾸었지만, 당연히 타사 기준엔 그런 게 없기에 Windows를 포함한 64비트 기반 프로그램에서는 '''인텔'''의 x64 기반 프로세서 아키텍처 식별자를 '''AMD64로 인식'''한다.
결국 이러한 명칭 싸움의 부작용으로 인해 AMD64를 인텔이 개발한 명령어 셋으로 오해하는 경우조차도 발생하고 있다. 일부 PC 정비사 서적에서 인텔 EM64T(이하 Intel64)를 인텔에서 개발한 64비트 아키텍처라고 설명한 부분이 있는데, 이는 모르는 사람이 볼 때 "인텔에서 독자적으로 개발한 기술"로 오해할 수 있다. 설명한 내용도 그런 식으로 되어있었다. 그런데 EM64T는 위에 서술된 것과 같이 AMD의 x86-64를 크로스 라이선스를 통해 도입한 명령어 셋이다. 추가로 이 서적들의 Intel64 설명 부분에 AMD 및 크로스 라이선스 관련 내용은 '''일절 없었다.'''
또한 아러한 명칭 싸움은 일반인들은 물론 컴덕들에게도 혼동을 일으키는 경우가 흔하다. 대표적으로 '''난 인텔 CPU 쓰는데, 왜 AMD64가 뜨냐?'''와 같은 질문을 흔히 볼 수 있다. 마이크로소프트에서는 AMD64보다는 x64라는 명칭을 많이 쓰지만, 리눅스를 다루는 사람들은 AMD64라는 명칭을 아주 흔하게 볼 수 있다.
다만, 이후 인텔이 루머상으로만 알려졌던 "AMD와의 협력"이 2018년에 새로 등장할 인텔 CPU 라인업을 통해 수면위로 떠오르면서 인텔과 AMD 간에 이런 아키텍처 명칭상에서의 껄끄러운 부분은 어느 정도 정리될 가능성이 있었다.[6] 하지만 라이젠의 출시와 CPU 게이트 이후 인텔의 CPU 개발이 지지부진해지면서 AMD와의 협력도 부진한 상태이며, 명칭 문제 따위는 신경 쓸 여유조차 없어진 상태에 이르렀다.

6. 관련 문서


[1] 부동소수점 파라미터가 있을 경우 전방 8개[2] System V AMD64 ABI[3] Windows XP x64 에디션은 영문판과 일본어판만 존재하며, 한글 등의 다른 언어는 영문판에다 언어팩을 설치해야 한다. 게다가 Windows Server 2003 기반이라 서비스 팩은 2밖에 없으며 호환성도 매우 나쁘다.[4] 오버워치의 경우 초창기에는 Windows Vista 64비트도 지원했다.[5] 볼드 처리된 부분은 실제로 그렇다는 게 아니라 인텔의 의도가 그렇다는 것이다. 확장된 것은 어찌됐든 맞는 말이긴 한데 '''약간''' 확장한 건 절대 아니기에 거짓말은 하지 않는다 수준의 눈 가리고 아웅이다. 저런 식이면 기존 인텔의 16비트 확장, 32비트 확장 CPU 모두 현실은 8비트, 16비트 CPU라는 게 된다.[6] 이 두 회사가 인텔의 CPU+AMD의 GPU 형태로 협력한 이유도 간단하다. '''NVIDIA-ARM-퀄컴'''이라는 삼각동맹이 성립되었는데, ARM의 CPU + NVIDIA의 GPU + 퀄컴의 통신 모듈의 조합으로 안드로이드 태블릿 및 크롬북 제품을 구글에 공급하는 쪽으로 가고 있기 때문이다. 즉, 기존의 x86 vs PowerPC로 대표되는 CPU 아키텍처 싸움이 90년대 말 x86의 승리로 끝난 후 20년만에 '''AMD64 vs ARM'''이라는 새로운 형태의 싸움으로 일어난 것이다.

분류