IA-64 Architecture : Itanium

다시 시작하는 인텔

8bit 8088 프로세서의 등장 이후 모든 인텔 프로세서의 명령어 셋은 기존 프로세서를 기반으로 만들어졌다. 32bit 386 프로세서가 새로운 멀티태스킹 기능을 가지고 등장하면서 커다란 변화가 시작되었으며, MMX와 SSE 멀티미디어 확장 기능이 포함되기에 이르렀다. 하지만 불행히도, 인텔은 기존 명령어에 대한 고수와 하위 호환성에 대한 집착은 최근의 프로세서를 더욱 복잡하게 제조하도록 만들수 밖에 없었다. 인텔은 파이프라인이나 branch 예측같은 RISC의 기능을 포함시키기 위해 칩을 훨씬 더 복잡하게 만들어야 했으며, Apple사 역시 68000 시리즈 프로세서에서 비슷한 문제에 부딪치기 되었다. 인텔을 거울삼아 Apple측은 기존의 어플리케이션을 에뮬레이션으로 구동시키는 완전히 새로운 PowerPC 칩을 개발하게 되었다. 수많은 새로운 프로세서가 개발된 현재 트랜지스터 양과 MHz를 증가시키는 속도가 둔화되는 문제에 직면하면서 인텔은 완전히 새로운 패러다임을 위해 기존의 아키텍쳐(IA-32라 알려진...)를 폐기하고 있다.

Itanium이 무엇인가?

대부분의 컴퓨터 매니아들은 Merced 프로세서와 같은 새로운 시스템에 친숙해 있을 것이다. 바로 얼마전 인텔은 Merced라는 코드명을(인텔 프로세서의 코드명은 모두 캘리포니아와 오레곤주의 강 이름에서 따온다.) 좀 더 프로페셔널한 Itanium이라 새로 바꾸었다. 이는 인텔이 펜티엄이라는 이름과 많은 금속 원소들의 이름이 -ium으로 끝난다는 점에서 착안하여 티타늄과 소리가 비슷한 이름으로 결정한 것으로 보여진다.

필자 개인적으로는 SR-71(전략 정찰기)에서 Big Bertha(1차대전 당시 독일군의 거대한 대포)의 조종사 머리에서 볼 수 있는 - 다소 머저리 같은 - 티타늄 부분이 연상되므로 특히나 이 이름이 마음에 들지 않는다.(역자주 : 필자 역시 유난스러운 이 글의 필자가 마음에 들지 않는다.) 물론, "나"의 생각이 인텔의 인터넷 캠페인인 "This way in"에는 아무런 영향을 미칠수 없음이 당연하다. Merced는 단지 IA-64 아키텍처가 구현된 최초의 프로세서일 뿐이다.  Merced의 실제 구현의 상세부는 아직 알려져있지 않으므로, 이 기사에서 논할 부분은 IA-64에 대한 혁신적인 것이 무엇이며, 그것이 어떻게 모든 수준의 최종 사용자에게 영향을 미칠지에 대해서이다.

어디에서 구입할 수 있는가?

아직은 구입이 불가능하다. Merced는 2년정도 계획보다 늦어진 상황이고, 현재로서는 2000년 중반경에 최초의 시스템을 볼 수 있을 것 같다. 물론, 이 칩을 위한 운영체제가 필요할 것이다. 인텔은 Merced(여러분이 Itanium을 고집한다면 그렇게 하자.)의 엔지니어링 샘플에서 리눅스와 Windows 2000을 포함하는 4개의 운영체제를 데모하고 있다. Merced는 서버 시장을 목적으로 할 것이므로, 최초의 시스템을 일반 사용자들이 사용하기는 힘들 것으로 보여진다.

잘 짜여진 소프트웨어 = 빠른 하드웨어

현재의 프로세서들은 이를 이용하는 소프트웨어에서 생각되는 것보다 훨씬 더 복잡하다. IA-32, MIPS, PowerPC와 같은 아키텍처 스펙이 기존 시스템과의 호환성을 유지하기 위해서는 칩 디자이너들로부터 침해되어서는 안된다. 프로세서의 성능을 향상시키는 방법은 두가지가 있다. 가장 확실한 방법은 클럭 속도(MHz)를 높이는 것이다. 이는 실제로 매우 빠른 프로세서가 느린 컴포넌트(일반적으로 메모리)와 상호 작업을 하는데 하드웨어(예를 들어 Cache와 같은...)를 추가하는 것 같이 더 발전되고 더 작은 공정을 이용하여 개선될수 있다.

두 번째 방법은 각 사이클에서의 평균 명령어 처리량을 증가시키는 것이다. 이는 파이프라인, 다중 실행 유닛, branch 예측과 같은 구조를 통해 구현되어진다. 여기에서 어려움 점은 프로세서상에서 구동되는 소프트웨어는 이러한 복잡성에 대해 알 길이 없다는 것이다. 코드의 각 부분은 단지 명령어의 흐름일 뿐이므로, 코드 상호간의 관계를 알 수 없으며 서로 충돌하는 것이 허용되지 않아야 한다. 이는 한번에 한 개의 명령어만을 실행할 때는 별다른 문제가 아니지만, 동시에 여러 명령어를 수행할 경우에는 서로 충돌하는 경우가 발생하게 된다. 현재의 프로세서들(펜티엄-III, G4 등)의 경우 이러한 충돌은 하드웨어에 의해 감지되고 보이지 않게 다루어져야 한다.

인텔, 분야를 바꾸다!

소비자들이 좀더 강력한 프로세서를 요구함에따라, 병렬 처리되는 명령어들 사이의 충돌을 감지하고 다루는 하드웨어는 믿기 어려울만큼 복잡해졌다. RISC는 명령어를 짧고, 일정한 길이로 만들어 실행이 간단하게 함으로써 이러한 문제를 해결하고 있다. 인텔은 기술적으로 기존 해법중 한가지를 사용하여 한발 더 나아가고 있다: 문제를 해결할수 없다면, 그에 대한 정의를 내림으로써 해결하라!

IA-64 아키텍처는 이전보다 하드웨어와 소프트웨어간의 밀접도를 더욱 많이 필요로 하고 있다. 인텔은 컴파일러(C++과 같은 하이레벨 언어에서 머신 코드로 바꿔주는...)를 통해 이를 가능하게 하였으며, 이는 프로세서가 코드부를 가장빠른 방법으로 실행할수 있도록 해준다. 컴파일러는 프로그램 전체 소스 코드를 접근하여 가장 빠르게 동작할 수 있도록 최적화시켜주므로 매우 중요한 위치를 차지한다. 반대로 프로세서는 프로그램을 빠른 명령어들의 연속적인 흐름으로 해석하며, 프로그램의 전후관계를 알아채는데는 어려움이 있다.

인텔은 결국 프로세서와 컴파일러의 상호 작용하는 방법을 재규정지음으로써 그들의 하드웨어 엔지니어들에게 훨씬 단순한 디자인의 매우 빠른 하드웨어를 생산할수 있도록 숨돌릴 틈을 안겨주었다. 그러나, 공짜는 없는법, 이러한 하드웨어 복잡성의 감소는 컴파일러 개발부에 그 부담을 이전시키고 있다. 이 부분에 대해서는 나중에 언급하기로 하자.

인텔은 말맞추기 게임을 하고 있다.

인텔은 IA-64가 RISC나 CISC의 범주에 포함되는데 반발, 대신 EPIC(Explicitly Parallel Instruction Code)라는 새로운 이름을 부여하고 있다. 이는 사실 RISC와 한동안 학교와 기업체의 연구실에서 연구되었던 VLIW(Very Long Instruction Word)의 아이디어를 접목시킨 것이다. Itanium 프로세서는 64bit 메모리 주소 공간(4GB의 펜티엄 한계를 넘어섰다.)에서 기인하여 64bit 프로세서라 불려지지만, 그 명령어 길이는 훨씬 복잡하다고 할 수 있다.

IA-64 명령어는 128bit의 묶음 내에 포함된다. 각 묶음은 41bit의 명령어와 5bit의 template code를 포함하고 있다. 모든 128bit는 한번에 프로세서에 의해 로드되어 처리될 수 있으며, templete code가 가리키는 것이 어떤 타입의 명령어이냐에 따라 이 세 명령어들은 각기 다른 실행 유닛(정수, 실수 등...)에서 처리된다. 128bit 묶음의 개수는 명령어 그룹에서 배열될 수 있으며, 명령어 그룹이란 명령어들이 병렬적으로 실행될 때 서로간에 충돌 없이 실행될 수 있는 명령어들의 스트림(흐름)이다.

예) 일반적으로 충돌은 RAW(Read After Write)시에 일어나게 된다. 아래에는 그러한 충돌이 일어나게 되는 예가 나타나 있다.(주: 독자들이 읽는데 도움을 주기 위해서 실제의 어셈블리 코드가 아닌 편의상의 가상(pseudo) 코드를 사용한다. 변수는 레지스터 또는 메모리 위치로 여겨질 수 있다.)
A = 1
B = 2
A = B + 1
B = A + 1
Display B
...다른 곳에서는 A나 B를 다루지 않는다.

만약 순서대로 실행이 이루어진다면, B는 결국 4가 되어야 한다. 그러나 파이프라인화된 프로세서에서 각 명령어는 다르게 작용할 수 있다. 즉, 세 번째 명령어가 끝나기 전에 네 번째 명령어가 시작되는 것이 가능하게 된다. 또한, 그 결과로 B는 2가 될 수도 있게 되는 것이다. 여러분은 프로세서가 이러한 문제를 감지하고 해결하기 위해서 얼마만큼 복잡한 구조를 가져야 하는지 이해하게 될 것이다. 이 작업은 네 번째 명령어가 시작되기 전에 세 번째 명령어가 끝나기를 기다려야 하므로 느려질수도 있을 것이다. IA-64 아키텍처에서는 컴파일러가 이러한 충돌을 피하기 위해 코드를 재배열하게 된다. 두 개의 세미콜론(;;)은 명령어 그룹들 간에 나누어져야 함을 나타낸다. 즉, 다음 명령어를 실행하기 전에 반드시 실행되어야 하는 코드를 나타내며, 이 명령어를 처리하는 유닛의 결과를 기다려 다른 명령어 처리에 반영해야 함을 나타낸다.

some instruction;;
A = 1
B = 2
A = B + 1;;
...다른 곳에서는 A나 B를 다루지 않는다.
B = A + 1
Display B
...

Itanium 컴파일러는 커다란 명령어 그룹들간에 충돌이 일어나지 않도록 코드를 새롭게 배열하여 주며, 이로인해 프로세서는 그룹들간의 dependency에 의한 것을 제외하고는 충돌을 지속적으로 점검할 필요가 없게 된다.