최근 수정 시각 : 2024-11-09 22:56:32

VLIW


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

1. 개요2. 상세3. 장점4. 단점5. 적용 제품

1. 개요

Very Long Instruction Word

1980년 전후로 예일대에 재학 중이던 조셉 피셔(Joseph Fisher)가 박사학위 취득을 위해 발표한 CPU 명령어 처리 기법이다.

2. 상세

병렬화된 컴퓨팅 기술에 관한 개념은 무려 1946년 앨런 튜링 등의 학자들이 연구한 수평적 프로그래밍 개념으로부터 기원한다. 명령어를 일반적인 튜링 머신처럼 선형으로 처리하는 것보다 서로간에 종속성이 없는 명령어들을 한꺼번에 처리하면 더욱 효율적일 것이라는 아이디어를 시작으로 명령 처리의 병렬화에 관한 연구가 이루어졌고 그 결과 중 하나가 VLIW다.

즉 CISC 방식의 복잡한 명령어를 내부적으로 쪼개어 일정한 명령어 크기를 갖도록 가공해 명령어 처리의 효율성을 높이는 것이 RISC라면 VLIW는 그냥 처음부터 디코드 유닛에 한꺼번에 종속성이 없는 여러 명령어를 때려박고 그걸 한번에 처리하여 효율성을 높이는 방식이다. VLIW 방식의 디코딩을 하려면 처음부터 들어오는 명령어들이 어느 정도 일정한 크기와 적은 종속성을 가지고 있다고 가정하고 소프트웨어적으로 명령어를 가공해 주어야 한다.

EPIC은 Explicitly Parallel Instruction Computing의 약자로, 휴렛 팩커드와 인텔에서 개발한 VLIW의 개량형이다. VLIW의 코드는 스케줄된 파이프라인에 묶여져 있기 때문에 파이프라인의 깊이나 실행 유닛의 결합을 바꾸는 것이 불가능하거나, 바꾸기 위해서는 코드를 다시 컴파일해야 한다는 단점이 있다. EPIC은 이러한 단점을 일부 해결했으며 레지스터 관련 기능 등이 추가되었다. 인텔 아이테니엄 시리즈가 EPIC을 채택했다.

만일 상기한 이상적인 상태가 주어진다면 VLIW방식의 명령어 디코딩은 비교적 단순한 하드웨어로 굉장한 명령어 처리 효율을 낼 수 있다. 그러나 하술할 단점들로 인해 1980년대~90년대를 거치며 많은 VLIW 방식으로 명령어를 처리하는 중앙처리장치들이 만들어졌음에도 대부분 혹평을 들었고 이후 하드웨어적으로 명령어를 최적화하고 코드 재배치를 하여 병렬로 실행하는 슈퍼스칼라와 비순차적 실행이 도입되면서 VLIW 방식은 그 장점을 완전히 잃어버려 일반적인 목적의 CPU 시장에서 사장되었다.

3. 장점

  • 이론적인 처리 속도는 정말 빠르다. 한번에 하나씩 처리하는 것보다는 당연히 여러개의 명령어를 한꺼번에 처리하는 것이 빠르다. VLIW 방식의 최대의 장점이다. 하지만 지금은 위에 서술한 기술의 발전으로 이러한 컴파일러와 명령어 삽질 없이 비슷한 성능을 누릴수 있어 더이상 장점으로 취급되지 않는다.
  • 다양한 명령어 크기와 종속성 분석이 쉽지 않은 CISC 방식 명령어의 파이프라이닝보단 미리 종속성을 제거하고 크기가 일정하게 들어오는 VLIW 방식 명령어의 파이프라이닝이 더 간단하다.

4. 단점

  • 컴파일러 설계 난이도가 매우 높다. VLIW 방식 명령어 처리의 가장 큰 단점. VLIW 방식의 명령어 처리 기법을 효율적으로 쓰려면 애초에 Fetch되는 명령어의 크기가 일정하게 되어야 할 필요가 있다. 그러나 그렇게 하려면 컴파일러가 미리 바이너리 파일을 만들때 내부의 이진 코드의 크기를 일정하게 만들고 종속성이 최대한 줄어들도록 재배치해 줘야 한다. 단순히 어셈블러를 바이너리 코드로 바꾸고 명령어 가공 및 스케줄링을 하드웨어에 맡기기만 하면 되는 RISC, CISC 방식의 컴파일러보다 컴파일러 제작 난이도가 더 높을 수밖에 없다.
  • 캐시 메모리 미스나 예외, 분기 예측 실패 등 명령어가 기대하던 대로 제때 들어오지 않고 잘못 들어올 상황에 처할 경우 같이 처리하기 위해 들어왔던 다른 명령어들까지 한꺼번에 빼고 다시 명령어를 읽어들여야 해서 예측 실패에 취약한 편이다.
  • 종속성이 지나치게 높은 코드가 들어올 경우 여러개의 명령어가 들어올 것을 가정한 유닛에 한두개의 명령어만이 한번에 처리되고 나머지 공간은 NOP(명령어 없음) 상태로 채워지게 되어 의외로 효율성이 떨어질 수 있다.

5. 적용 제품

분류