문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 CISC (문단 편집) === 단점 === * '''구조가 복잡해 프로세서 설계가 힘들다.''' RISC를 탄생시킨 결정적인 이유이다. 마이크로코드를 받으면 이를 해독해야 하는데, 해독 자체도 어려워 디코더 설계가 까다로우며 해독한 뒤에는 버퍼를 거쳐 명령어를 재정렬 해야하는 등 시퀀싱도 복잡하다. 프로세서 설계가 전체적으로 어렵기 때문에, 1970년대에 [[IBM]]에서 CISC를 대체할 [[RISC]] 프로세서를 개발하였고, 현재 CISC 진영의 대표 주자인 인텔에서는 80년대 나온 [[VLIW]]를 90년대 채택하는 등 아이태니엄의 실패 이전까지 꾸준히 [[x86]]을 포기하려고 시도하였다. * '''파이프라이닝 구현이 매우 어렵다.''' 일정한 길이로 작게 쪼개진 마이크로코드를 사용하는 RISC는 코드를 바로 파이프라인에 투입하면 되므로 파이프라이닝 구현이 쉽다. 하지만 CISC는 어떤 길이의 마이크로코드가 입력될지 알 수 없기 때문에 이를 적절하게 쪼개 파이프라인으로 전달해줘야 해, 파이프라이닝 구현이 RISC에 비해 난해하다. 이 때문에 고성능 상용 RISC CPU에 들어가있던 파이프라이닝이, CISC에서는 슈퍼컴퓨터에서나 찾아볼 수 있는 기술이었다. 나중에 인텔이 [[슈퍼스칼라]]를 뜯어고치면서 이 문제를 해결할 방법을 찾고 나서야 CISC 프로세서의 파이프라이닝 구현 난도가 확 낮아졌지만, 파이프라이닝의 효율은 그래도 RISC가 CISC보다 높으며 파이프라이닝의 확장도 RISC가 쉽고 CISC는 확장이 어려운 편이다. 지금의 x86 계통 CPU들이 CISC로 작동하는데 내부는 RISC로 명령어를 처리하는 괴상한 혼종이 된 이유가 파이프라이닝을 제대로 구현해내기 위해 RISC의 구조를 일부 수용했기 때문이다. * '''디코더가 비대해짐''' 마이크로코드를 해독해야 하는 디코더가 굉장히 비대해진다. x86계 CPU들이 가진 대표적인 문제점이기도 한데, 이는 CISC 구조가 (특히 가변 길이 명령어 인코딩이) 야기한 선천적인 부작용이라 그렇다. 지금은 반도체 공정의 발전으로 트랜지스터를 늘리기 쉽지만, 예전에는 프로세서의 가용 트랜지스터 수가 굉장히 제한적이었다. 그런데 CISC는 디코딩이 복잡해 CISC 프로세서의 디코더가 커질 수 밖에 없어 많은 트랜지스터를 디코더가 혼자 독식하는 일이 비일비재했다. 다른 유닛도 트랜지스터를 할당 받아 성능 확장을 해야 했지만, 디코더가 트랜지스터를 거의 다 가져가 성능향상에 발목 잡히는 일이 흔했다. 그리고 디코더의 중요성이 매우 커, 디코더를 못 만들면 아키텍처 전체의 성능이 눈에 띄게 떨어지는 문제가 있었다.(이건 반대로 디코더를 잘 만들면, 프로세서 아키텍처의 성능을 크게 끌어올릴 수 있단 이야기가 된다.) 이 디코더에 많은 트랜지스터가 집적되기 때문에 큰 전력소모와 높은 발열 문제를 야기한다. RISC는 이런 문제를 피할 수 있어, 프로세서의 전력소모량과 발열 줄이는게 쉽다. 반대로 CISC 같은 경우는 프로세서의 거의 50퍼센트에 가까운 전력을 디코더가 소모하는 등 순수 CISC 프로세서는 디코더가 전력문제와 발열의 주범이다. 다만 현대적인 CISC 프로세서들은 디코더에 가해지는 부하를 줄이는 uOP 캐시가 도입되고 성능에 있어 [[분기 예측]], [[비순차적 실행]]과 같은 설계들이 도입되고 있어 무작정 디코더가 CISC의 발목을 잡는다는 표현은 과거와 달리 항상 유효하다고 보기는 어렵다. 실제로 디코더가 작은 RISC나 RISC보다도 디코더가 더 작은 [[VLIW]] 계열이 90년대 한창 유행했으나 RISC는 아직도 CISC를 완전히 밀어내지 못했고 인텔은 2010년대 말 [[VLIW]] 계열 CPU인 [[인텔 아이태니엄 시리즈]]를 단종시킨다. 이런식으로 현대 [[x86]]프로세서와 같은 RISC화 된 CISC의 경우 인스트럭션 디코더가 사용하는 전력은 전체의 5%도 되지 않으며[* uOP 캐시는 CISC 명령어의 주소에 디코드된 uOP들을 대응시키는 구조의 캐시인데, 특수 목적용 프로그램이 아닌 이상 대부분의 프로그램은 SIMD 벡터를 제외하면 {{{mov}}}, {{{lea}}}, {{{push}}}, {{{pop}}} 같은 Load/Store I/O, {{{sub}}}, {{{add}}}, {{{mul}}}, {{{div}}} 와 같은 정수/실수연산과 {{{shr}}}, {{{shl}}}과 같은 시프트연산과 {{{and}}}, {{{or}}}, {{{xor}}}, {{{cmp}}}, {{{jz}}}, {{{jnz}}}, {{{je}}}, {{{jne}}} 같은 비교/분기 명령어 등 1-2개의 RISC식 uOp에 대응되는 명령어가 대부분을 차지하고, 대부분의 시간동안 특정한 루프를 반복하므로 (=자주 쓰이는 코드는 한정적) uOP 캐시의 적중률이 높은 편이다. 레이턴시가 길고 3개 이상의 동작을 해 uOP 캐시를 이용하기 어려운 복잡한 명령어는 AMD64 기준 {{{SHLD/SHRD}}}, {{{PUSHA}}}, {{{BSF/BSR}}} 5개 명령어와 일부 특수 명령어 정도밖에 되지 않는다.] OpCache의 Hitrate 가 떨어져 디코더가 다시 동작하는 상황에서도 3% 에서 10%로 증가하는것에 불과하며 나머지는 L1, L2 와 같은 인스트럭션 캐시와 순수 연산부분이 프로세서 소비전력의 90%이상을 차지한다. [* [[https://www.usenix.org/conference/cooldc16/workshop-program/presentation/hirki|Empirical Study of Power Consumption of x86-64 Instruction Decoder]]] * '''특정 환경에서 RISC보다 비효율적''' 코드의 과대포장의 문제이다. RISC로 절제해 입력할 수 있는 마이크로코드를, 그것도 CISC에서는 이상적으로만 작성한다면 더 간단하게 입력할 수 있는 코드를 인적인 문제 때문에 과도하게 크게 만들어 성능을 저하시키는 문제이다. CISC는 코드 길이를 가변적으로 입력할 수 있기에, 프로그래머의 실력이 떨어지면 코드를 필요 이상으로 길게 작성하는 일이 발생해 큰 퍼포먼스 저하를 유발할 수 있다. [* ({{{xor eax, eax}}}), ({{{mov eax, 0}}}), ({{{sub eax, eax}}}), ({{{and eax, 0}}}) 등등 모두 같은 역할을 하지만 모두 기계어의 길이가 다르다. ({{{xor eax, eax}}})는 ({{{0x31 0xC0}}})로 2바이트 명령어지만 ({{{and eax, 0}}})는 ({{{0x83, 0xE0, 0x00}}})으로 3바이트, ({{{mov eax, 0}}})은 ({{{0xbb, 0x00, 0x00, 0x00, 0x00}}})으로 4바이트 명령어다.] * '''기술의 발전으로 의미를 잃은 장점들''' 코드 밀도가 높아 메모리 사용량을 줄일 수 있는 장점은 메모리가 보급되면서 큰 의미는 아니게 되었다. GUI 환경에서 가장 큰 용량을 차지하는 부분은 데이터이기 때문이기도 하다. 또한 일부 RISC 구조 CPU에서 가변 길이 명령어를 도입하기도 했으며, 이는 가변 길이 명령어가 더 이상 CISC만의 전유물이 아니게 되었음을 나타낸다. 대표적으로 [[ARM(CPU)|ARM]]의 Thumb-2 명령어 세트와 [[RISC-V]]가 있다. 하지만 일부 제품군을 제외한 ARM 아키텍처 제품군의 경우 이는 완벽한 가변 길이 명령어 체계가 아니며 중간에 모드 변환 명령어를 실행해야 한다. 그렇지 않다면 프로세서가 오작동하게 된다. x86은 완벽한 가변 길이 명령어 체계를 가지므로 RISC CPU들과는 동작이 다르다.저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기