#!if 넘어옴1 != null
''''''{{{#!if 넘어옴2 == null
{{{#!if 넘어옴1[넘어옴1.length - 1] >= 0xAC00 && 넘어옴1[넘어옴1.length - 1] <= 0xD7A3
{{{#!if ((넘어옴1[넘어옴1.length - 1] - 0xAC00) % 28) == 0
는}}}{{{#!if ((넘어옴1[넘어옴1.length - 1] - 0xAC00) % 28) != 0
은}}}}}}{{{#!if 넘어옴1[넘어옴1.length - 1] < 0xAC00 || 넘어옴1[넘어옴1.length - 1] > 0xD7A3
은(는)}}}}}}{{{#!if 넘어옴2 != null
, ''''''{{{#!if 넘어옴3 == null
{{{#!if 넘어옴2[넘어옴2.length - 1] >= 0xAC00 && 넘어옴2[넘어옴2.length - 1] <= 0xD7A3
{{{#!if ((넘어옴2[넘어옴2.length - 1] - 0xAC00) % 28) == 0
는}}}{{{#!if ((넘어옴2[넘어옴2.length - 1] - 0xAC00) % 28) != 0
은}}}}}}{{{#!if 넘어옴2[넘어옴2.length - 1] < 0xAC00 || 넘어옴2[넘어옴2.length - 1] > 0xD7A3
은(는)}}}}}}}}}{{{#!if 넘어옴3 != null
, ''''''{{{#!if 넘어옴4 == null
{{{#!if 넘어옴3[넘어옴3.length - 1] >= 0xAC00 && 넘어옴3[넘어옴3.length - 1] <= 0xD7A3
{{{#!if ((넘어옴3[넘어옴3.length - 1] - 0xAC00) % 28) == 0
는}}}{{{#!if ((넘어옴3[넘어옴3.length - 1] - 0xAC00) % 28) != 0
은}}}}}}{{{#!if 넘어옴3[넘어옴3.length - 1] < 0xAC00 || 넘어옴3[넘어옴3.length - 1] > 0xD7A3
은(는)}}}}}}}}}{{{#!if 넘어옴4 != null
, ''''''{{{#!if 넘어옴5 == null
{{{#!if 넘어옴4[넘어옴4.length - 1] >= 0xAC00 && 넘어옴4[넘어옴4.length - 1] <= 0xD7A3
{{{#!if ((넘어옴4[넘어옴4.length - 1] - 0xAC00) % 28) == 0
는}}}{{{#!if ((넘어옴4[넘어옴4.length - 1] - 0xAC00) % 28) != 0
은}}}}}}{{{#!if 넘어옴4[넘어옴4.length - 1] < 0xAC00 || 넘어옴4[넘어옴4.length - 1] > 0xD7A3
은(는)}}}}}}}}}{{{#!if 넘어옴5 != null
, ''''''{{{#!if 넘어옴6 == null
{{{#!if 넘어옴5[넘어옴5.length - 1] >= 0xAC00 && 넘어옴5[넘어옴5.length - 1] <= 0xD7A3
{{{#!if ((넘어옴5[넘어옴5.length - 1] - 0xAC00) % 28) == 0
는}}}{{{#!if ((넘어옴5[넘어옴5.length - 1] - 0xAC00) % 28) != 0
은}}}}}}{{{#!if 넘어옴5[넘어옴5.length - 1] < 0xAC00 || 넘어옴5[넘어옴5.length - 1] > 0xD7A3
은(는)}}}}}}}}}{{{#!if 넘어옴6 != null
, ''''''{{{#!if 넘어옴7 == null
{{{#!if 넘어옴6[넘어옴6.length - 1] >= 0xAC00 && 넘어옴6[넘어옴6.length - 1] <= 0xD7A3
{{{#!if ((넘어옴6[넘어옴6.length - 1] - 0xAC00) % 28) == 0
는}}}{{{#!if ((넘어옴6[넘어옴6.length - 1] - 0xAC00) % 28) != 0
은}}}}}}{{{#!if 넘어옴6[넘어옴6.length - 1] < 0xAC00 || 넘어옴6[넘어옴6.length - 1] > 0xD7A3
은(는)}}}}}}}}}{{{#!if 넘어옴7 != null
, ''''''{{{#!if 넘어옴8 == null
{{{#!if 넘어옴7[넘어옴7.length - 1] >= 0xAC00 && 넘어옴7[넘어옴7.length - 1] <= 0xD7A3
{{{#!if ((넘어옴7[넘어옴7.length - 1] - 0xAC00) % 28) == 0
는}}}{{{#!if ((넘어옴7[넘어옴7.length - 1] - 0xAC00) % 28) != 0
은}}}}}}{{{#!if 넘어옴7[넘어옴7.length - 1] < 0xAC00 || 넘어옴7[넘어옴7.length - 1] > 0xD7A3
은(는)}}}}}}}}}{{{#!if 넘어옴8 != null
, ''''''{{{#!if 넘어옴9 == null
{{{#!if 넘어옴8[넘어옴8.length - 1] >= 0xAC00 && 넘어옴8[넘어옴8.length - 1] <= 0xD7A3
{{{#!if ((넘어옴8[넘어옴8.length - 1] - 0xAC00) % 28) == 0
는}}}{{{#!if ((넘어옴8[넘어옴8.length - 1] - 0xAC00) % 28) != 0
은}}}}}}{{{#!if 넘어옴8[넘어옴8.length - 1] < 0xAC00 || 넘어옴8[넘어옴8.length - 1] > 0xD7A3
은(는)}}}}}}}}}{{{#!if 넘어옴9 != null
, ''''''{{{#!if 넘어옴10 == null
{{{#!if 넘어옴9[넘어옴9.length - 1] >= 0xAC00 && 넘어옴9[넘어옴9.length - 1] <= 0xD7A3
{{{#!if ((넘어옴9[넘어옴9.length - 1] - 0xAC00) % 28) == 0
는}}}{{{#!if ((넘어옴9[넘어옴9.length - 1] - 0xAC00) % 28) != 0
은}}}}}}{{{#!if 넘어옴9[넘어옴9.length - 1] < 0xAC00 || 넘어옴9[넘어옴9.length - 1] > 0xD7A3
은(는)}}}}}}}}}{{{#!if 넘어옴10 != null
, ''''''{{{#!if 넘어옴10[넘어옴10.length - 1] >= 0xAC00 && 넘어옴10[넘어옴10.length - 1] <= 0xD7A3
{{{#!if ((넘어옴10[넘어옴10.length - 1] - 0xAC00) % 28) == 0
는}}}{{{#!if ((넘어옴10[넘어옴10.length - 1] - 0xAC00) % 28) != 0
은}}}}}}{{{#!if 넘어옴10[넘어옴10.length - 1] < 0xAC00 || 넘어옴10[넘어옴10.length - 1] > 0xD7A3
은(는)}}}}}} 여기로 연결됩니다. #!if 설명 == null && 리스트 == null
{{{#!if 설명1 == null
다른 뜻에 대한 내용은 아래 문서를}}}{{{#!if 설명1 != null
{{{#!html IA-64 아키텍처 기반 프로세서}}}에 대한 내용은 [[인텔 아이태니엄 시리즈]] 문서{{{#!if (문단1 == null) == (앵커1 == null)
를}}}{{{#!if 문단1 != null & 앵커1 == null
의 [[인텔 아이태니엄 시리즈#s-|]]번 문단을}}}{{{#!if 문단1 == null & 앵커1 != null
의 [[인텔 아이태니엄 시리즈#|]] 부분을}}}}}}{{{#!if 설명2 != null
, {{{#!html }}}에 대한 내용은 [[]] 문서{{{#!if (문단2 == null) == (앵커2 == null)
를}}}{{{#!if 문단2 != null & 앵커2 == null
의 [[#s-|]]번 문단을}}}{{{#!if 문단2 == null & 앵커2 != null
의 [[#|]] 부분을}}}}}}{{{#!if 설명3 != null
, {{{#!html }}}에 대한 내용은 [[]] 문서{{{#!if (문단3 == null) == (앵커3 == null)
를}}}{{{#!if 문단3 != null & 앵커3 == null
의 [[#s-|]]번 문단을}}}{{{#!if 문단3 == null & 앵커3 != null
의 [[#|]] 부분을}}}}}}{{{#!if 설명4 != null
, {{{#!html }}}에 대한 내용은 [[]] 문서{{{#!if (문단4 == null) == (앵커4 == null)
를}}}{{{#!if 문단4 != null & 앵커4 == null
의 [[#s-|]]번 문단을}}}{{{#!if 문단4 == null & 앵커4 != null
의 [[#|]] 부분을}}}}}}{{{#!if 설명5 != null
, {{{#!html }}}에 대한 내용은 [[]] 문서{{{#!if (문단5 == null) == (앵커5 == null)
를}}}{{{#!if 문단5 != null & 앵커5 == null
의 [[#s-|]]번 문단을}}}{{{#!if 문단5 == null & 앵커5 != null
의 [[#|]] 부분을}}}}}}{{{#!if 설명6 != null
, {{{#!html }}}에 대한 내용은 [[]] 문서{{{#!if (문단6 == null) == (앵커6 == null)
를}}}{{{#!if 문단6 != null & 앵커6 == null
의 [[#s-|]]번 문단을}}}{{{#!if 문단6 == null & 앵커6 != null
의 [[#|]] 부분을}}}}}}{{{#!if 설명7 != null
, {{{#!html }}}에 대한 내용은 [[]] 문서{{{#!if (문단7 == null) == (앵커7 == null)
를}}}{{{#!if 문단7 != null & 앵커7 == null
의 [[#s-|]]번 문단을}}}{{{#!if 문단7 == null & 앵커7 != null
의 [[#|]] 부분을}}}}}}{{{#!if 설명8 != null
, {{{#!html }}}에 대한 내용은 [[]] 문서{{{#!if (문단8 == null) == (앵커8 == null)
를}}}{{{#!if 문단8 != null & 앵커8 == null
의 [[#s-|]]번 문단을}}}{{{#!if 문단8 == null & 앵커8 != null
의 [[#|]] 부분을}}}}}}{{{#!if 설명9 != null
, {{{#!html }}}에 대한 내용은 [[]] 문서{{{#!if (문단9 == null) == (앵커9 == null)
를}}}{{{#!if 문단9 != null & 앵커9 == null
의 [[#s-|]]번 문단을}}}{{{#!if 문단9 == null & 앵커9 != null
의 [[#|]] 부분을}}}}}}{{{#!if 설명10 != null
, {{{#!html }}}에 대한 내용은 [[]] 문서{{{#!if (문단10 == null) == (앵커10 == null)
를}}}{{{#!if 문단10 != null & 앵커10 == null
의 [[#s-|]]번 문단을}}}{{{#!if 문단10 == null & 앵커10 != null
의 [[#|]] 부분을}}}}}}#!if 설명 == null
{{{#!if 리스트 != null
다른 뜻에 대한 내용은 아래 문서를}}} 참고하십시오.#!if 리스트 != null
{{{#!if 문서명1 != null
* {{{#!if 설명1 != null
IA-64 아키텍처 기반 프로세서: }}}[[인텔 아이태니엄 시리즈]] {{{#!if 문단1 != null & 앵커1 == null
문서의 [[인텔 아이태니엄 시리즈#s-|]]번 문단}}}{{{#!if 문단1 == null & 앵커1 != null
문서의 [[인텔 아이태니엄 시리즈#|]] 부분}}}}}}{{{#!if 문서명2 != null
* {{{#!if 설명2 != null
: }}}[[]] {{{#!if 문단2 != null & 앵커2 == null
문서의 [[#s-|]]번 문단}}}{{{#!if 문단2 == null & 앵커2 != null
문서의 [[#|]] 부분}}}}}}{{{#!if 문서명3 != null
* {{{#!if 설명3 != null
: }}}[[]] {{{#!if 문단3 != null & 앵커3 == null
문서의 [[#s-|]]번 문단}}}{{{#!if 문단3 == null & 앵커3 != null
문서의 [[#|]] 부분}}}}}}{{{#!if 문서명4 != null
* {{{#!if 설명4 != null
: }}}[[]] {{{#!if 문단4 != null & 앵커4 == null
문서의 [[#s-|]]번 문단}}}{{{#!if 문단4 == null & 앵커4 != null
문서의 [[#|]] 부분}}}}}}{{{#!if 문서명5 != null
* {{{#!if 설명5 != null
: }}}[[]] {{{#!if 문단5 != null & 앵커5 == null
문서의 [[#s-|]]번 문단}}}{{{#!if 문단5 == null & 앵커5 != null
문서의 [[#|]] 부분}}}}}}{{{#!if 문서명6 != null
* {{{#!if 설명6 != null
: }}}[[]] {{{#!if 문단6 != null & 앵커6 == null
문서의 [[#s-|]]번 문단}}}{{{#!if 문단6 == null & 앵커6 != null
문서의 [[#|]] 부분}}}}}}{{{#!if 문서명7 != null
* {{{#!if 설명7 != null
: }}}[[]] {{{#!if 문단7 != null & 앵커7 == null
문서의 [[#s-|]]번 문단}}}{{{#!if 문단7 == null & 앵커7 != null
문서의 [[#|]] 부분}}}}}}{{{#!if 문서명8 != null
* {{{#!if 설명8 != null
: }}}[[]] {{{#!if 문단8 != null & 앵커8 == null
문서의 [[#s-|]]번 문단}}}{{{#!if 문단8 == null & 앵커8 != null
문서의 [[#|]] 부분}}}}}}{{{#!if 문서명9 != null
* {{{#!if 설명9 != null
: }}}[[]] {{{#!if 문단9 != null & 앵커9 == null
문서의 [[#s-|]]번 문단}}}{{{#!if 문단9 == null & 앵커9 != null
문서의 [[#|]] 부분}}}}}}{{{#!if 문서명10 != null
* {{{#!if 설명10 != null
: }}}[[]] {{{#!if 문단10 != null & 앵커10 == null
문서의 [[#s-|]]번 문단}}}{{{#!if 문단10 == null & 앵커10 != null
문서의 [[#|]] 부분}}}}}}| <bgcolor=#96834a> 명령어 집합 | |
| CISC | AMD64●x86● · M68K · 68xx · Z80 · 8080 · MOS 65xx · VAX |
| RISC | Arm 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 |
1. 개요
인텔이 휴렛 팩커드와 공동으로 개발한 VLIW 기반 64비트 ISA이며, 2001년 처음 출시되어 2021년 단종된 인텔 아이태니엄 시리즈 프로세서에 적용되었다.2. 특징
기존 32비트 ISA인 x86과는 전혀 무관한 새로운 설계의 64비트 ISA이며, 당시만 해도 혁신적인 설계를 도입했던 터라 당시 64비트 시장의 지배적인 위치로 떠오를 것으로 예상됐으나, 실상은 전혀 그렇지 않았다. IA-64 제품인 아이태니엄이 출시 지연 및 수많은 문제점으로 인해 서버 시장에서 AMD에서 내놓은 AMD 옵테론 시리즈에 밀린 것은 물론이고, 기존 x86을 확장한 AMD의 AMD64(x86-64)에 묻혀 잊혀진 존재가 됐다.| |
| 전망(파란색)과 큰 차이를 보이는 실제 판매 결과(주황색) |
이후에도 인텔의 IA-64 살리기 노력이 간간히 지속됐지만, 2000년대 후반 정도가 되면서 사실상 흑역사가 확정됐다. 2017년 아이태니엄의 마지막 모델을 출시했고 2021년을 마지막으로 IA-64 프로세서는 모두 단종되었다.
3. 역사
3.1. 개발
1994년에 최초로 발표됐을 당시, IA-64는 IA-32(=x86)에서 시장의 절대 강자가 된 인텔과 PA-RISC 및 HP-UX를 만들던 휴렛 팩커드의 협력 덕에 64비트 시장에서의 기존 경쟁자인 MIPS, DEC Alpha, SPARC, POWER, PowerPC 등의 RISC 칩들을 모조리 물리칠 것으로 예상됐었다. 이에 따라, 당시 서버 시장을 매의 눈으로 노리고 있던 마이크로소프트를 위시하여 기존 서버 업체였던 IBM, 썬 마이크로시스템즈, 실리콘 그래픽스 등의 회사들도 IA-64 기반 서버를 개발했다.IA-64의 커다란 특징은 경쟁 마이크로프로세서들과 전혀 다른 VLIW(EPIC)을 채택했다는 점이었다. EPIC은 Explicitly Parallel Instruction Computing의 약자로, VLIW의 일종이다. VLIW는 Very Long Instruction Word의 약자로, CISC에 비해 한 개의 명령어를 극히 단순화시켜 처리의 효율성을 추구하는 RISC와 달리, 무지막지하게 긴 명령어를 통해서 처리의 효율성을 꾀한다. 즉, 명령어 여러 개를 한 사이클당 한 명령어씩 실행하는 방식이 아닌, 여러 가지 명령어들 중 병렬 실행이 가능한 명령어들 세 개를 이어 붙여서 하나의 긴 명령어로 만들어 그 긴 명령어 하나를 한 사이클에 처리하는 것이다. 하지만 VLIW의 코드는 스케줄된 파이프라인에 묶여져 있기 때문에 파이프라인의 깊이나 실행 유닛의 결합을 바꾸는 것이 불가능하거나, 바꾸기 위해서는 코드를 다시 컴파일해야 한다는 단점이 있다. EPIC은 VLIW 구조에 RISC를 참조해서 이러한 단점을 해결했으며 레지스터 관련 기능 등이 추가됐다. #
인텔이 x86 대신 IA-64를 선택한 이유는 1994년경에 이미 x86이 구닥다리 소리를 듣고 있었기 때문이다. 최초의 x86 아키텍처 CPU인 8086이 1978년에 나왔고 8086 당시 만들어진 명령어 집합의 확장판 격인 IA-32도 1985년 80386과 같이 등장했기 때문이다. RISC가 x86의 문제점에 대한 반동으로 등장한 시점이 이미 1980년대 중반이며, 또 다른 CISC 회사였던 모토로라는 자사의 모토로라 68000 제품군을 버리고 호환성이 없는 RISC 기반의 PowerPC로 이전할 예정이었다. 때문에 그 상업적 성공에도 불구하고, 펜티엄은 경쟁하던 타사의 RISC 마이크로프로세서에 비해 전력 소비량이 많으면서도 성능이 전반적으로 떨어졌다. 새로운 미래 지향적 아키텍처로 명령어 집합 길이가 일정하고 구조가 간단하며 메모리 접근 명령어가 분리된 RISC의 장점을 살려 레지스터 숫자를 늘린다든가, 파이프라인을 최적화하여 클럭을 올린다든가, 명령어 해석기가 줄어들면서 칩 크기를 줄여 생산 단가를 절감하고 전력 효율을 달성하고 있던 타사와 달리, 인텔의 x86은 CISC 명령어 집합을 채택한 까닭에 구조도 복잡하고 하위 호환성을 보장하기 위한 부분을 계속 유지하면서 같은 크기의 칩에 상대적으로 적은 수의 레지스터를 올릴 수밖에 없었기에 필연적으로 성능 향상에 한계가 있었다. 당시 아직 32비트였던 PowerPC마저도 64비트를 염두에 둔 명령어 집합이 이미 준비되어 있었다.
즉 x86의 문제점은 이미 인텔을 포함한 업계의 공감을 얻고 있는 상황이었으며 문제는 그것을 어떻게 해결하는가였다. 여기에서 인텔이 선택한 것은 32→64비트로의 이전과 동시에 VLIW 구조를 채용한 IA-64였다. 반면 경쟁 업체였던 AMD는 AMD64를 통해 그 문제를 끌어안고 가면서 개선하는 방법을 선택했고 양사의 선택은 불과 몇 년 후 명암이 갈리게 됐다.
3.2. 현실과 몰락
인텔은 IA-32로 데스크탑 시장을 지배하는 것과 동시에 타사의 RISC를 능가할 VLIW 명령어 집합을 채택한 우수한 IA-64 마이크로프로세서 아키텍처로 서버 시장까지도 석권하여 그랜드슬램을 달성할 차세대 유망주로 기대됐다. 하지만 여러 가지 이유로 현실은 그러지 못했다.- 우선 개발이 늦어졌다. 최초의 IA-64 프로세서는 당초 예정이었던 1999년이 아니라 2001년에 나왔다. 이는 VLIW 문서에서도 보다시피 컴파일러 개발이 굉장히 어렵기 때문이었다. 개발이 한없이 길어지자 결국 완성도가 높지 않은 상태에서 출시했고, 이는 또다른 문제를 야기했는데 아래 개발 환경의 문제에서 자세히 서술했다. 당시에는 CPU 성능이 1년 반마다 2배씩 올라가는 CPU 기술 발전의 황금기였으므로 2년의 출시 지연은 치명적일 수밖에 없었다.
- 개발 지연과 맞물려 성능에서 별반 뛰어난 모습을 보여주지 못했다. 당시 다른 RISC 칩에 비해서도 별반 나을 게 없었다.
- CPU의 성능을 발휘할 수 있도록 해 줄 새로운 명령어 집합에 맞는 프로그램은 거의 없었던 반면, IA-32(x86) 명령어 에뮬레이션 하드웨어는 성능이 너무 떨어져 기존 프로그램들은 기대 이하의 결과를 냈다. 심하면 VLIW로 돌리는 것에 비해 속도가 1/10밖에 안 나오는 경우도 있었다. 그래서 IA-64가 x86 또는 IA-32와 단절적 이행을 시도했다고 오해하는 경우가 많은 이유가 바로 이것이다. 이후 윈도우와 리눅스 진영에서 소프트웨어로 만든 에뮬레이터가 50% 이상 빨랐을 정도였다. 결국 아이태니엄 서버들은 '버추오조'(Virtuozzo) 같은 서드파티 가상화 프로그램에 기댈 수밖에 없었다. 이는 AMD의 AMD64 지원 CPU가 x86 명령어 실행 속도에 아무 문제가 없었던 것에 비하면 심각한 문제였다. 결국 2006년에 인텔은 뒤늦게 저 하드웨어를 제거하고 IA-32 Execution Layer라는 소프트웨어 에뮬레이터를 만들어 배포했으나 너무 늦었다.
- 그러면서도 거대한 칩 면적으로 인해 가격이 심히 비쌌다.
- 인텔의 x86이 이용하는 CISC 방식 또한 공정 미세화가 진척되면서 가용 트랜지스터 숫자가 늘어나는 상황이 지속되자 1994년 NexGen NX586을 시작으로 AMD K5 시리즈, 인텔 펜티엄 프로 이후의 x86 프로세서에는 RISC처럼 x86 명령어 집합을 작은 마이크로 연산(micro-operation, μops)으로 번역해 실행하는 기능이 들어갔고, 1999년 AMD 애슬론 시리즈부터 클럭 경쟁으로 성능이 일취월장하면서 EPIC의 장점은 큰 의미가 없어졌다.
- 개발 환경의 문제. IA-64 컴파일러의 저열한 성능과 문제점도 만만치 않았다. 컴파일 시간이 기존의 2~3배로 늘어나는 것은 기본이고 다른 컴파일러에서는 멀쩡하게 컴파일 됐던 소스 코드도 알 수 없는 온갖 오류를 내며 컴파일 되지 않는 경우가 허다했다. 이는 VLIW 구조가 그 특성 상 명령어 레벨의 병렬성(Instruction-Level Parallelism)을 찾는 부하가 CPU의 스케줄러에서 대거 컴파일러로 전가되면서 컴파일러 설계가 복잡다난해졌기 때문이다. 물론 새 아키텍처로 바뀌면서 컴파일러에 삽질하는 것은 으레 있는 일이었기에 시간이 약일 수도 있었으나, 아이태니엄이 충분히 오랫동안 버티지 못한 관계로[1] 결국 이 문제는 해결되지 않았다.
뒤늦은 초기 출시 이후에도 아이태니엄 칩의 성능은 좀처럼 향상되지 않았고, 2003년에 x86 위에 64비트 명령어를 확장시킨 AMD64가 등장하고 인텔도 2004년 코드명 얌힐을 공개하여 AMD64 지원을 발표하면서 사실상 데스크탑 시장으로의 아이태니엄 도입 시도는 인텔의 항복으로 끝나고 말았다. 실제로 CPU 아키텍처 교재로 유명한 '컴퓨터 구조 및 설계'의 저자 페터슨 교수 등은 이 사건에 대해 인텔이 항복했다는 표현을 해당 교재에 실제로 수록했다. 그나마 순화된 표현이 arstechnica의 편집장의 인텔이 자신의 실수를 인정했다 정도.
이후 2004년 휴렛 팩커드도 아이태니엄 개발을 포기하고 인텔에게 개발 보조금을 지급하는 방식으로 바뀌었고 인텔만이 개발하게 됐으며, 마이크로소프트도 Windows XP Professional 64-bit Itanium 버전의 판매를 종료하고 Professional x64 Edition을 판매하기 시작한다. 하지만 이 역시 Windows Server 2003 기반이라 제대로 된 지원은 아니었다. Windows Vista에서 AMD64를 제대로 지원했으나, 아직 호환성 문제 등이 제대로 해결되지 않은 시기였으며[2], 본격적으로 64비트 운영 체제로 쓰이기 시작한 건 Windows 7이다. Windows Server 역시 Windows Server 2008 R2까지 지원하다가, Windows Server 2012에서 아이태니엄 지원을 중단하여 마이크로소프트는 완전히 손을 떼고 만다. 레드햇과 오라클도 모든 소프트웨어 개발 포기를 천명했고, 마지막까지 남은 건 휴렛 팩커드의 아이태니엄용 HP-UX 뿐이다. 이 시점에서는 인텔도 아이태니엄을 내던지고 싶은데 공동 개발사인 휴렛 팩커드와의 계약 관계 때문에 억지로 끌고 나가는 상황이었다. 심지어는 아이태니엄용 HP-UX의 메이저 업데이트도 2007년이 마지막이었고, 휴렛 팩커드 또한 이 즈음에 아이태니엄에 대한 희망을 놓은 것으로 보인다.
2011년까지 남아있는 아이태니엄의 세력은 적극적으로 일본 시장에 파고들어서 살아남은 NEC 등의 독자적인 메인 프레임 시장 및 HP-UX 서버 일부에만 잔존한 상태다. 인텔에서 파악한 바로는 2011년 기준 아이태니엄 시장의 크기는 40억 달러로 추산했다. 슈퍼컴퓨터 TOP500 에서도 2004년에 1위를 한 NASA의 슈퍼컴퓨터 컬럼비아가 아이태니엄 2를 1만개나 때려박아서 달성했다. 시장 점유율도 한때 10~20%를 차지했지만 지금은 목록에서 안 보인다.
결국 아이태니엄의 상태는 계륵만도 못한 사실상 버린 자식이다. 인텔과 휴렛 팩커드 입장에서도 기존 고객들을 x86-64 기반의 제온 서버로 계속 이주를 시키고 있는 판이지만, 중요한 대규모 인프라에 아이태니엄을 여전히 쓰고 있는 일부 고객들과의 약속이 걸린 문제이기 때문에 아직도 라인업을 유지는 시키고 있는 것. 심지어 2016년 2월에 나온 기사로는 새 아이태니엄은 휴렛 팩커드를 통해 주문 제작을 받는 식으로 만들어질 것이라는 이야기까지 들릴 지경.
4. 사용자 아키텍처
4.1. 명령어 인코딩
IA-64는 명령어를 128비트(16바이트) 크기의 번들 단위로 인코딩하며, 한 번들에는 최대 3개의 명령어가 포함될 수 있다. 하나의 번들에는 5비트 크기의 template 필드에 각 명령어가 사용하는 유닛의 종류 및 "stop"의 위치를 기록한다. 각각의 명령어는 41비트 크기로 인코딩된다. 이때 일반적인 RISC 명령어와 달리 template 값에 따라 같은 필드의 값도 다른 명령어로 해석될 수 있으므로 주의.| 명령어 필드 | 형식(template) | 명령어 1 | 명령어 2 | 명령어 3 |
| 비트 수 | 5-bit | 41-bit | 41-bit | 41-bit |
여기서 "stop"은 개념상 명령어 사이에 위치하여 의존 관계를 나타내는 표지이며, 의존 관계를 stop을 사용하여 명시적으로 표현함으로써 불필요한 NOP의 발생을 줄이고, 프로세서의 너비 및 실행 유닛 구성이 명령어 아키텍처에 의해 제약받지 않도록 할 수 있다.
각각의 명령어에는 6비트 크기의 qualifying predicate 필드가 있어 predicate 레지스터의 값에 따라 실행 여부가 결정된다. 명령어에 따라 100가지 이상의 세부 인코딩이 존재하기 때문에 모든 인코딩을 나열하지는 않는다.
Template field의 값에 따라 각 명령어는 다음과 같은 실행 유닛에 배정된다:
- I-unit: opcode에 따라 I-type 또는 A-type 명령어를 인코딩한다.
- M-unit: opcode에 따라 M-type 또는 A-type 명령어를 인코딩한다.
- F-unit: FP 명령어(F-type)를 인코딩한다.
- B-unit: Branch 명령어(B-type)를 인코딩한다.
- X-unit: 명령어 필드 2개를 합쳐 큰 크기의 immediate 값을 포함하는 X-type 명령어를 인코딩한다.
4.2. Predication
IA-64 아키텍처의 핵심 기능 중 하나로, 분기 예측(Branch Prediction) 실패에 따른 파이프라인 지연을 줄이기 위해 도입되었다. 모든 명령어는 64개의 Predicate Register(p0~p63) 중 하나를 참조하며, 해당 레지스터의 값이 참(True, 1)일 때만 결과가 반영(Commit)되고, 거짓(False, 0)이면 해당 명령어는 NOP(No Operation)처럼 취급되어 실행되지 않는다.예를 들어 C언어의
if (a > b) c = d; else e = f;와 같은 구문은 분기 명령어 없이 다음과 같이 처리될 수 있다.cmp.gt p1, p2 = rA, rB(rA > rB인지 비교하여 결과에 따라 p1과 p2를 상호 반대로 설정)(p1) mov rC = rD(p1이 참일 때만 실행)(p2) mov rE = rF(p2가 참일 때만 실행)
이를 통해 작은 조건문의 경우 분기 예측 실패로 인한 파이프라인 플러시(Flush) 비용을 완전히 제거할 수 있다. p0은 항상 참(True)으로 고정되어 있어, 일반적인 무조건 실행 명령어는
(p0)을 생략한 것으로 간주한다.4.3. Speculation
메모리 지연 시간(Memory Latency)을 숨기기 위해 데이터가 실제로 필요하기 전에 미리 로드하는 기법을 하드웨어적으로 강력하게 지원한다. 크게 제어 추측(Control Speculation)와 데이터 추측(Data Speculation)으로 나뉜다.- Control Speculation: 분기 명령어보다 앞서 데이터를 로드할 때 사용한다. 만약 로드 과정에서 예외(Exception)가 발생하더라도 즉시 처리하지 않고, 타겟 레지스터의 NaT(Not a Thing) 비트를 설정한다. 이후 실제로 데이터를 사용하는 시점에
chk.s명령어로 NaT 비트를 검사하여 예외 처리를 수행한다. - Data Speculation: 값을 저장하는 스토어(Store) 명령어보다 앞서 로드(Load)를 수행할 때 사용한다. 스토어와 로드의 주소가 겹치는지(Aliasing) 확실하지 않을 때 유용하다. 고급 로드(
ld.a)를 수행하면 ALAT(Advanced Load Address Table)에 항목이 생성되고, 이후 스토어 명령어가 해당 주소를 덮어쓰면 ALAT 항목이 무효화된다. 데이터를 사용하기 전에chk.a명령어로 ALAT를 확인하여, 데이터가 오염되었다면 다시 로드한다.
4.4. 레지스터
- 128개의 범용 레지스터
- 128개의 FP 레지스터
4.4.1. 레지스터 스택
일반적인 명령어 아키텍처에서는 caller와 callee가 동일한 레지스터를 사용할 수 있으므로 함수 또는 프로시저의 시작 및 끝 부분에서 불필요한 레지스터의 spill 및 fill이 발생하게 된다. IA-64는 "register stack"을 도입하여 caller와 callee의 동일한 번호의 레지스터가 서로 다른 실제 레지스터를 가리키게 하는 설계를 도입하였다.4.4.2. 레지스터 회전
소프트웨어 파이프라이닝(Software Pipelining)을 돕기 위해 도입된 기능이다. 루프가 한 번 반복될 때마다 레지스터의 논리적 번호가 이동한다. 예를 들어, 루프의 첫 실행에서 r32에 저장된 값은 다음 반복에서 r33으로 접근 가능하다. 이를 통해 루프 내에서 변수 이름을 바꾸지 않고도 파이프라인 단계별로 데이터를 유지할 수 있어, 루프 언롤링(Loop Unrolling) 없이도 높은 병렬성을 달성하고 코드 크기를 줄일 수 있다.5. 커널 아키텍처
5.1. 가상 메모리
IA-64는 매우 광범위한 64비트 가상 주소 공간을 지원하며, 이를 효율적으로 관리하기 위해 독특한 주소 변환 구조를 가진다.- Region (영역): 가상 주소의 상위 3비트는 8개의 Region 중 하나를 선택하는 데 사용된다. 각 Region은 별도의 Region Register(RR)에 의해 관리되며, 여기에 24비트의 Region ID(RID)가 저장된다. 이를 통해 프로세스 간에 주소 공간을 쉽게 공유하거나 격리할 수 있다.
- Protection Keys (보호 키): 페이지 단위의 접근 권한 제어 외에도, Protection Key 레지스터를 통해 더 세밀한 메모리 보호를 지원한다.
- TLB 및 VHPT: 하드웨어적으로 관리되는 TLB(Translation Lookaside Buffer) 외에도, 메모리에 위치한 가상 해시 페이지 테이블(VHPT, Virtual Hash Page Table)을 하드웨어가 자동으로 탐색(Page Walker)할 수 있어 TLB 미스 처리 성능을 높였다.
6. 명령어 목록
#!if (문단 == null) == (앵커 == null)
를#!if 문단 != null & 앵커 == null
의 [[IA-64/명령어 목록#s-|]]번 문단을#!if 문단 == null & 앵커 != null
의 [[IA-64/명령어 목록#|]] 부분을7. 여담
8. 관련 문서
[1] 아래 서술되어 있듯이 인텔은 아이태니엄으로 별 재미를 못보자 2011년에 컴파일러 팀을 대부분 해체했다. 이는 아이태니엄이 단종되기 10년 전 일이었다.[2] 일반적인 프로그램은 문제가 없지만, 64비트를 지원하지 않는 장치 드라이버나 백신 프로그램 등이 있었기 때문에 문제가 됐다.