1 개요
AMD에서 개발한 x86을 64비트로 확장한 아키텍처이다. AMD64, x86-64, x64라고도 불린다.
2 역사
64비트 컴퓨팅 시장을 놓고 인텔과 AMD는 서로 다른 꿈을 꾸고 있었다. 인텔은 x86의 문제점을 알고 있었기 때문에 1994년에 개발을 시작한 IA-64를 통해서 64비트로 단절적 이행을 생각하고 있었고, 이 때문에 아이태니엄 프로세서는 x86 호환성이 없었다. AMD는 x86 구조를 유지한 채 자체적으로 64비트로 확장하기로 결심했고, 1999년 x86-64라는 이름으로 64비트 확장 x86명령어 셋을 발표했다. x86-64가 탑재되어 출시된 첫 제품은 2003년에 나온 슬레지해머 기반 옵테론이며, 결국 인텔도 2004년 프레스캇에서 x86-64를 지원하는 방향으로 선회하면서 업계의 사실상 표준으로 자리잡게 되었다. 그 와중에 아이태니엄 IA-64는 침몰하게 되었고
3 특징
90년대를 풍미했던 32비트 기반 주요 명령어셋들이 64비트로 확장되었을 때의 보여줬던 방식들을 무리 없이 잘 따라갔다. 주요 변경점을 살펴보면,
- 주요 레지스터 크기가 32비트에서 64비트로 확장되었다. 대중적으로 마케팅할 때 나오는 64비트라는 말이 주요 레지스터의 크기를 가리키는 말이다.
- x86의 기존 8개 레지스터인 EAX, EBX, ECX, EDX, ESP, EBP, ESI, EDI는 특수 기능이 할당되어 있었기 때문에, 전용과 범용 레지스터 사이의 기능을 가지고 있었다. x86-64에는 R8-R15 레지스터 8개가 추가되어 범용 레지스터가 16개가 되었다. ARM 등 다른 아키텍처에 비하면 레지스터 수가 부족하지만, x86의 고질적인 레지스터 부족이 크게 완화되었다.
- SSE 레지스터 숫자가 XMM0-XMM7 8개에서 XMM0-XMM15 16개로 확대되었다.
- 기존 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에서 레거시 모드를 사용하면 되었다.
- x86-64에서 64비트 확장 명령어들은 명령어 앞에 1바이트의 접두사가 붙는 것으로 구분되었다. 이럴 경우 64비트 모드의 코드에서 32비트를 다루기 위한 명령어를 아무런 변경 없이 그대로 쓰면서 접두사에 의해 유발되는 코드 길이 증가를 억제할 수 있게 된다.
- NX bit가 추가되었다. 이는 메모리 안정성과 보안성 향상을 위한 기능으로 특히 버퍼 오버런 공격에 대한 취약성을 개선하기 위한 것으로, 2012년 가을에 출시된 Windows 8부터는 이 기능이 필수로 요구되기 시작했다. 인텔 CPU에서는 XD bit라는 이름으로 사용하고 있다.
- 여기에서 명령어셋트의 모습을 볼 수 있다.
4 전개
x86-64가 2003년 클로우해머, 즉 애슬론 64로 시장에 도입되어 인기를 끌고 인텔도 이듬해 초 프레스캇부터 지원을 시작한 후 CPU에서는 대부분 x86-64를 지원하게 되면서 x86-64는 빠른 속도로 IA-32를 이어 시장에서 사실상의 표준의 위치를 점하게 되었다.
다만 OS와 애플리케이션은 CPU 시장의 추세만큼 빠르게 64비트로 전환하지 못 했다. 리눅스는 애슬론 64가 출시되기 이전인 2001년부터 AMD64를 지원하기 시작했고, 64비트 리눅스 배포판은 상당히 빠르게 출시되었다. 커널과 유저랜드 모두가 오픈소스인 특성 상 프로그램의 64비트 지원이 윈도우에 비하면 상당히 빠른 편이었다. 그래서 대용량 데이터를 다룰 필요가 있는 시스템은 64비트 리눅스로 빠르게 전환했다.
반면 윈도우 쪽은 리눅스에 비하면 64비트 전환이 상당히 느렸다. 2005년에 Windows XP x64 에디션이 출시되었으나, 사실상 NT 커널 버전이 다른 윈도우 2003을 개인용으로 끌어 내린 버전이었기 때문에 별 반향 없이 넘어갔다. 2006년 말의 Windows Vista에서는 확실하게 x86-64를 지원하였으나, 윈도우 비스타 자체가 실패해버렸고, 결국 2009년 가을 Windows 7이 성공하고 나서야 윈도우 시장에도 x86-64가 안착하게 된다. 이후 64비트 점유율 상승은 PC에 들어가는 RAM 용량의 증가세에 의해 좌우되었다. 2010년대 이전부터 이미 32비트 OS의 메모리 지원 용량을 초월해버렸기 때문.
윈도우 쪽 프로그램은 소스 코드가 공개되지 않는 경우가 대부분이고, 따라서 64비트 윈도우에서도 32비트 바이너리 코드를 돌려야 할 필요성이 많았다. 그래서 32비트 윈도우에 비해서 64비트 윈도우는 32비트 라이브러리까지 다 포함해야 했기 때문에 디스크 공간도 더 많이 필요했고, 프로그램 개발자 입장에서도 32비트 바이너리가 그대로 도는 상황에서 64비트 컴퓨팅으로 확실한 이득을 얻을 수 있는지 확신이 어려웠기 때문에 64비트 전환이 지지부진했다. 64비트 웹 브라우저나 탐색기에서는 32비트 플러그인을 돌릴 수 없었기 때문에 Internet Explorer는 32비트가 기본으로 탑재되어 있었고, 탐색기도 셸 확장 때문에 윈도우 비스타까지는 32비트가 기본값이었으나 7 출시 직전에 64비트가 기본값이 되었다.
하지만 리눅스 쪽은 커널과 프로그램의 소스 코드가 대부분 공개되어 있기 때문에 단순히 다시 컴파일하는 것 만으로 64비트 지원을 도입하기 상당히 쉬웠다. 덕분에 리눅스 세계는 64비트 웹 브라우저가 일찍부터 상용화되어 있었고, 64비트 웹 브라우저 플러그인에 대한 수요가 있었다. 대표적으로 어도비 플래시 플레이어도 2011년에 64비트 플러그인을 모든 플랫폼으로 정식 출시했지만, 그보다 훨씬 이전인 2008년부터 리눅스 전용 알파 버전을 출시해 왔다. OS X 쪽은 애플의 가차 없는 과거 호환성 던져 버리기 덕분에 64비트 도입이 적극적이었다. 애시당초 애플이 컴퓨터에 사용했던 32비트 인텔 프로세서가 인텔 코어 시리즈밖에 없었고, 애플 TV 1세대에만 펜티엄 M을 잠깐 사용했기 때문에 OS X 10.4와 10.5만 32비트 커널을 사용했고, 10.6 이후부터는 64비트 커널이 기본값이 되었다.
게임 분야는 2012년부터 일부 고사양 게임들은 아예 처음부터 64비트 OS에서만 실행할 수 있도록 제작되고 있다. AAA급 게임은 그래픽 비중이 높아 메모리 사용량이 커서 기존 3GB 정도의 RAM 정도로는 절대적으로 부족하기 때문이다. 2016년 현재는 출시되고 있는 대부분의 AAA급 게임(특히 사양이 높은 FPS 게임들)은 64비트 OS만 지원하고 있다.
5 뒷이야기
x86-64의 이름이 AMD64, Intel64, 얌힐, IA-32e, EM64T, x64 같은 여러 이름으로 불리게 된 이유는 x86-64를 둘러싼 Intel과 AMD 두 회사간의 알력이라고 쓰고 대부분은 인텔의 삽질이라고 읽어도 된다의 결과이다.
처음 AMD가 x86-64라는 이름으로 IA-32의 64비트 확장 계획을 1999년도에 발표했을 때, 인텔의 공식적 입장은 IA-32는 별도의 64비트화 계획이 없고, IA-64가 인텔의 차세대 64비트라는 것이었다. 그러나 이러한 결정으로 인해 후술하듯이 인텔 내부에서 희대의 내부 음모 사건이 일어나는 계기가 되었는데... 당시 프레스캇의 기초설계를 진행하고 있던 인텔 오레건 설계 팀에서 x86-64를 적용한 설계를 얌힐이라는 코드명 아래 비밀리에 시작했다. 여기까지는 어느 업체에서나 볼 수 있는 그러한 비밀 프로젝트인 것 처럼 보였다. 그런데 문제는 그 비밀의 범위였다. 무려 회장님과 경영진에게도 비밀로 진행 했다는 것이다. 최고경영진이 자사 최신 제품의 기본 스펙을 모르게 개발하는 게 가능한 회사 조직이라는 것은 막장 그 자체라는 것. 이는 인텔 경영층이 2000년도 즈음에 얼마나 내부적으로 문제가 많은 상태였는지 알려주는 에피소드로, 인텔의 주요 실책성 의사결정들이 딱 그 시기에 쏟아져 나왔다는 것이 우연의 산물이 아니라는 증거일 수 있다.
이후 2003년에 x86-64 기반의 옵테론과 애슬론 64가 출시되어 시장에서 큰 인기를 얻게 되면서 인텔의 신형 프레스캇에 x86-64가 이미 포함되었다는 루머가 꾸준히 올라오게 된다. 이것이 이른바 얌힐의혹으로 당시 내로라 하는 벤치마크 사이트들이 얌힐의 다이 사진까지 분석해가면서 관련 의혹을 제기했으나, 인텔은 이를 꾸준히 부인하였다. 그리고 2004년 드디어 프레스캇이 시장에 데뷔하면서 기존에 얌힐로 알려져 있던 인텔판 x86-64를 대외적으로 발표하게 되는데... 이것을 x86-64가 아닌 IA-32e라는 이름으로 발표하는 삽질을 다시 한 번 저지르게 된다. 인텔의 작명 의도는 x86-64가 단순히 IA-32를 약간 확장한 것에 불과하니까 IA-32e일 뿐이라는 것이었으나, 문제는 이렇게 발표해 놓고 보니 프레스캇이 64비트를 지원한다는 사실이 가려져 버리면서 가뜩이나 문제가 많은 프레스캇의 제품 경쟁력을 스스로 디스해 버리는 사태가 벌어지고 만 것.
결국 인텔은 새로운 작명을 하게 되는데, 이번에는 또다시 괴악하기 짝이 없는 Extended Memory 64bit Tech, 줄여서 EM64T라는 이름을 붙여 버렸다. 즉 자사 제품이 단순하게 64비트 메모리 확장 기능만 가지고 있는 것으로 격하시켜 버린 것. 이러한 일련의 작명 실책들의 배경에는 인텔이 64비트 명령어 셋의 적자嫡子는 여전히 IA-64임을 지키려는 의도가 숨어 있었으나, 결국 인텔이 IA-64 기반으로 만든 아이태니엄 시리즈가 흑역사가 되면서 이러한 시도는 희극이자 비극으로 막을 내리게 된다.
한가지 더, AMD 역시 x86-64가 시장에서 물이 오르는 시점에서 그동안의 중립적인 명칭이었던 x86-64를 AMD64라는 이름으로 말뚝박기를 시전하면서 약간의 실수를 저질렀으나, 사실 이것은 그다지 실책이라고 할 수준은 아니다. 어차피 x86-64의 소유권은 명확히 AMD의 것이기 때문이다. 그것에 대한 인텔의 대응은 AMD가 원 저작자임이 분명한 x86-64를 무려 Intel64라는 이름으로 바꾼 것이었다. 재밌는 부분은 Intel64도 윈도우를 포함한 64비트 기반 프로그램에서는 프로세서 아키텍처를 AMD64로 인식한다. 정의는 승리한다!
결국 이러한 명칭 싸움의 부작용으로 인해 x86-64를 인텔이 개발한 명령어 셋으로 오해하는 경우조차도 발생하고 있다. 일부 PC 정비사 서적에서 인텔 EM64T(이하 Intel64)를 인텔에서 개발한 64비트 아키텍처라고 설명한 부분이 있는데, 이는 모르는 사람이 볼 때 "인텔에서 독자적으로 개발한 기술"로 오해를 할 수 있다. 설명한 내용도 그런 식으로 되어있었다. 그런데 EM64T는 위에 서술된 것과 같이 AMD의 x86-64를 크로스 라이센스를 통해 도입한 명령어 셋이다. 추가로 이 서적들의 Intel64 설명 부분에 AMD 및 크로스 라이센스 관련 내용은 일절 없었다.