문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 CISC (문단 편집) === 장점 === * '''작지만 고밀도의 코드를 사용''' 하나의 마이크로코드에 많은 명령어들을 담아내므로 코드의 밀도가 높다. 특히 이는 지금의 컴퓨터가 왜 RISC가 아닌 CISC로 시작을 했는지 보여주는데, CISC를 사용하면 프로그램의 용량을 줄일 수 있고 메모리 접근 횟수를 크게 줄일 수 있다. CISC의 장점은 바로 적은 지시로 많은 작업을 처리할 수 있단 점이다. 특히 컴퓨터 발전 초기에는 경악할만한 비용의 메모리를 사용하던 시절인데다 사용할 수 있는 메모리 용량도 매우 한정적이라, 메모리 관련 비용을 절감하고 안그래도 부족했던 메모리 용량을 아끼면서 사용할 수 있는 CISC가 매우 유리하다 보니 CISC가 제일 먼저 탄생해 현장에서 이용됐다. * '''생산성이 높다(마이크로코드 작성이 쉽다)''' 코드 단위당 작업량이 매우 많다. CISC는 가변 길이 마이크로코드를 사용하므로, 16 = 4 x 4와 같이 CISC로 단 하나의 코드로 해결할 수 있는 작업을, RISC로는 2+2+2+2+2+2+2+2의 코드를 입력해야 해 마이크로코드 작성자 입장에선 CISC가 매우 편리하다. 즉 CISC는 생산성이 높다. [* 그 예시로 어떤 두 값을 비교 후 비교 결과에 따라 다른 값을 저장해야 할 때 CISC인 x86은 CMPXCHG 명령어 하나로 Lock, Load, Compare, Store 작업이 한번에 끝나고 Register operends 에 따라 비교 대상의 크기를 지정할 필요가 없지만 RISC 프로세서들의 경우 최소 4단계의 오퍼레이션이 필요하고 비교 대상의 레지스터에 따라 모든 구현을 직접 해야한다. [[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/include/asm/cmpxchg.h#n254|Linux arm/include/asm/cmpxchg.h]] ] * '''호환 명령어''' RISC는 CPU 구조가 바뀌어 처리 비트 단위에 변화가 생기면 기존의 명령어를 사용할 수 없어 호환성의 문제를 일으킨다. CISC는 구조상 프로세싱 단계에 꼭 들어맞아야 할 최적 명령어의 개념이 없어, 하드웨어 단계에서 지원하는 명령어를 후속 프로세서에서도 지원해준다면 명령어의 호환성을 크게 신경쓰지 않아도 된다. 호환 명령어의 사용이 가능하다 보니 프로그래머가 거의 쓰이지 않는 CPU 명령어로만 프로그래밍을 하지 않는 이상 호환성이 확보된다. 그리고 프로세서 구조를 바꾸어도 호환 명령어를 통해 호환성이 확보되므로, 프로세서 설계자들은 급진적인 설계 변화와 혁신적인 구조의 아키텍처 개발을 지속할 수 있다. [* 예를 들어 CISC계열인 x86의 명령어를 예로 들면 {{0x8c6131}} 명령은 [[8086|16비트]], [[IA-32|32비트]], [[AMD64|64비트]] 모두 "{{{mov word ptr [(bx+di), (ecx), (rcx) + 0x31], fs}}}"로 레지스터 크기만 달라지고 동작이 동일하다.] 이 덕분에 사실상 반쯤 추상화된 인스트럭션을 어떻게 해석하고 재 배치하는지에 따라 성능의 차이를 보여줘 오래된 코드들 또한 새로운 프로세서에서 성능상 이점을 주게 되는것에 비해 [[RISC]]와 같이 프로세서 파이프라인을 감안해 코드를 만들어 줘야 하는 RISC계열 프로세서의 경우 프로그래머와 컴파일러의 중요성이 높아지게 된다. 이 문제가 극대화된 프로세서가 [[VLIW]].저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기