336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
글쓴이 : 임장섭 (2002년 03월 21일 오전 04:34) 읽은수: 2,250 [ 새소식 인쇄용 페이지 ]

Special Report

RISC는 임베디드에 유용한가?

하나의 프로젝트를 시작할 때 그 구성요소를 선택하는 것은 무척 어려운 결정이다. 그 중 중요한 결정 중의 하나는 RISC(Reduced Instruction Set Computer)와 CISC(Complex Instruction Set Computer) 중 하나를 선택하는 것이다. CISC는 요즘 기술이 빠르게 진보한다는 점을 가만하면 비교적 오래된 것이긴 하지만, 아직도 성능이 우수하며 CISC를 선택하는 것이 더 현명할 때도 있다.

새로운 프로젝트를 시작할 시점이라고 가정해보자. 당신은 마이크로프로세서를 선택해야 할 것이다. 32비트 프로세서가 필요하다고 결정하긴 했지만, 그 중 어떤 것인가? 100가지 이상의 다양한 32비트 임베디드 칩 중에 하나를 선택해야 한다. 따라서, 그 중 마음에 드는 몇 가지로 선택의 폭을 좁혀야 한다. 그렇다면 아마도 당신은 RISC 프로세서를 골랐을 것이다.
대부분의 프로그래머와 엔지니어들은 이렇게 말할 것이다. "요즘은 프로세서가 다 RISC 아냐?" RISC는 현대적이고 더 빠르며 더 매력적이다. 한마디로 더 호감이 간다.
그러나 최신 유행에 민감한 대부분의 엔지니어들은 인정하기 힘들지 몰라도, 10년 된 CISC 칩을 선택하는 것이 요즘 나온 RISC 칩을 선택하는 것보다 너 나을 수도 있다. 물론 항상 그런 것은 아니지만, 실제 설계자들이 느끼는 것보다는 더 자주 있는 일이다. CISC 칩은 아직도 건재하며, 대부분의 인기있는 RISC보다도 더 선호되고 있다. 모토로라와 MIPS사는 32비트 프로세서 판매에서 1, 2위를 다투고 있으며, 1998년 기준으로 각각 8,330만 개, 5,000만 개의 판매고를 기록했다. 인텔의 CISC dinosaur(68K인 것으로서)도 1,230만 개의 높은 판매량을 기록한 제품이다. CISC는 RISC라는 용어가 생기고 나서 생긴 용어다. 세계대전(Great War)이 2차 세계대전(World War Ⅱ)이란 말이 생긴 이후 1차 세계대전(World War I)으로 바뀌어 불렸듯이, CISC란 표현은 이와 반대 개념인 RISC란 용어가 생김에 따라 나오게 된 용어다.

RISC란 무엇인가?
우선, RISC란 실제로 무엇인가와 RISC가 무엇을 의미하는 지를 구분해서 알아보자.
RISC는 reduced instruction set computer의 약자로서 컴퓨터(혹은 그 내부의 프로세서)가 축약형 명령 셋을 가지고 있음을 암시한다. 그것은 CPU Lite와 같다. 당신은 RISC가 마이크로프로세서의 분해된 형태일 뿐이라고 냉소적으로 말할 수도 있다. 부분적으로는 맞는 말이다.
RISC의 개발원리는 프로세서를 완전히 분해하는 것이었다. 꼭 필요한 요소가 아니면 다 버렸다. 이것은 프로그래머의 관점에서 볼 때, 때로는 RISC 칩이 간단한 곱셈도 할 수 없다는 것을 의미한다. 그 의견은 곱셈은 단순히 반복되는 덧셈이기 때문에 ADD 명령이 충분히 좋아야 한다는 것이다.
RISC가 처음 부상하기 시작한 1980년대에 UC Berkeley와 Stanford에선 무슨 생각을 하고 있었을까? 무어의 법칙에 의해, 매달 칩 디자이너에게 4%의 하드웨어를 넣는 것은 축소를 위해 바람직하지 않은 것으로 생각했다. RISC의 기초가 되는 아이디어는 복잡한 기능은 하드웨어가 아닌 소프트웨어에서 더 효율적으로 행해진다는 것이다. 소프트웨어는 하드웨어보다 바꾸기 쉽고, 업데이트하기 쉬우며 더 빨리 만들어 낼 수 있다. 새로운 칩을 설계해서 만드는 것보다 새로운 코드를 쓰는 것이 더 빠르다. 따라서 RISC를 기반으로 하는 컴퓨터는 더 빨리 업그레이드될 수 있다. 프로그램과 알고리즘은 기록시간에서 변경되고 향상되어 진다. 무엇보다도 RISC 하드웨어는 단순화되고 능률적으로 되어가기 때문에 칩도 더 빨리 작동할 수 있다. 모두가 다 좋은 것이다.
본래의 RISC 칩은 CISC의 반대 개념으로서의 현재 RISC보다 더 작고 단순했으며 빨랐다.
68020과 80286과 같은 프로세서가 수년간 축적해 온 것들을 버림으로써 SPARC와 MIPS 같은 RISC가 만들어졌다.
클록 주파수의 측면에서 RISC는 완전한 승리자였다. 기술 잡지와 산업간행물들은 RISC의 등장을 컴퓨터의 신기원이라고 환호했다.
주위에서 가장 빠른 프로세서를 찾으라고 한다면 누구나 인텔의 펜티엄을 선택할 것이다. 이것이 당신이 구할 수 있는 가장 빠른 프로세서라는 것이 애통할 만한 일이었다. 그렇다면 SPARC는? 썬사의 워크스테이션은 현재 가장 느린 32비트 칩 중의 하나에 의해 가동되고 있다.
뭐가 잘못된 것인가? 확실히 1990년대에는 RISC를 둘러싼 과장이 많았다. RISC가 PC산업에서의 인텔의 압도적인 우세를 꺾을 마지막 기회로 보여졌기 때문에 어느 정도는 이해가 간다. 만약 RISC가 반값으로 두 배의 성능을 보여주었다면(절대 실현될 수 없는데도 종종 반복되는 주장) 확실히 전세계는 인텔과 그 독점회사들을 포기했을 것이다. RISC는 가진 것 없는 자들의 마지막 희망이었다.
동시에 RISC의 기세는 인텔을 포함한 CISC 벤더들을 자극했다. 모토로라는 68030과 68040으로 68K 제품군을 확장시켰고, x86 아키텍처는 68386과 68486으로 한 단계 나아갔다.
하지만, 하나의 예외로 인해 그들은 그렇게 할 수 없었다. 68K 프로세서는 클록 속도가 대부분의 32비트 칩보다 뒤떨어져 최대치가 남들이 세 자리 숫자일 때 66 MHz 이었다. 요즘도 대부분의 68K 프로세서는 100 MHz 이하의 속도에서만 사용할 수 있다.
이것이 CISC 프로세서의 죽음을 이야기하는가? CISC는 영원히 사장되고 마는 것인가?
그렇지 않다. 클록 속도에서는 종종 뒤쳐지지만 68K와 x86 같은 CISC 칩은 아직도 충분한 능력을 수행하고 오히려 RISC 보다 더 낫다. CISC 칩은 고려해 볼만한 가치 이상의 것이며 때론 임베디드 시스템을 위한 최고의 선택이 되기도 한다.

장점과 단점
RISC 아키텍처로 얻을 수 있는 것은 직교명령집합(orthogonal instruction set)이 있는 비교적 간단한 CPU이다. 모든 명령은 같은 길이를 가지고 있어 RAM에 깔끔하게 정렬된다. 또한 비슷하게 엔코더 되기 때문에 RISC opcode를 해체하고자 한다면 작업이 쉬워진다. 메모리에서 명령을 카운트하는 것도 쉽다. 마지막으로 RISC 명령은 거의 항상 단일 클록 사이클에서 실행되기 때문에 특정 루틴의 사이클 수를 계산할 수 있다.
RISC는 명령이나 혹은 당신이 좋아할 지도 모르는 다른 기능들이 없다. 우선 수학이 있다. 대부분의 RISC 칩에는 원래 곱하거나 나누는 명령이 없다. 그리고 대부분은 아직도 나누기를 못한다. 당신이 어셈블리 언어 프로그래머라면 축하한다. 당신은 정수를 곱하고 나누기 위해 코드 루틴을 소유하게 된다. 부동 소수점 계산은 신경 쓰지 않아도 된다. 대부분의 RISC 칩은 이 기능도 없다. 대부분의 CISC 칩에도 FPU(부동소수점처리장치)가 없지만 새로운 RISC 칩보다는 오래된 CISC 프로세서에서 더 자주 볼 수 있다.
또한 bit twiddling도 없다. 시스템에 레지스터나 다른 주변장치가 많다면 프로세서가 32 bit word보다 적은 것을 처리하지 않을 때 더 곤란해진다. 많은 RISC 설계자들은 단일 비트 구동을 명백하게 이단 시 했다. 예를 들어, 상태 레지스터(status register)에서 단일 비트를 체크하고 고정(toggle)하기 위해 당신은 프로세서로 들어가는 메모리의 전체 레지스터(그리고 그 주위 메모리 32비트 전체 혹은 I/O)를 읽어야만 한다.
정렬되지 않은 메모리 액세스는 RISC의 또 다른 골칫거리다. RISC 칩은 워크스테이션을 위해 설계되었는데, 워크스테이션에선 컴파일러가 항상 워드 경계를 따라 데이터를 정렬해 놓는다(바이트처럼). 더 작은 수는 존재하지 않거나 32비트 단어에 맞추기 위해 zero-pad된다. 임베디드 시스템에서는 좀처럼 그렇게 깔끔하지 않다.
홀수 어드레스에 저장된 32비트처럼 메모리 경계 주위를 둘러싼 숫자는 많은 RISC 칩에 접근하기 어렵다. 그들은 정렬되지 않은 연산 수를 다룰 수가 없다. 마찬가지로 24-bit 값과 같이 odd-sized quantity는 저장될 때 zero-extend 또는 sign-extended 되어야만 하므로 결과적으로 RAM을 낭비한다.
좋은 소식은 컴파일러는 이 중 어떤 것도 감지하지 못한다는 것이다. 당신이 어셈블리 언어 프로그래머라면 RISC가 곤혹스러울 것이다. 만약 당신이 컴파일러를 가지고 C나 다른 고수준(high level) 언어로 프로그램을 쓴다면 이러한 제약을 거의 깨닫지 못하게 될 것이다. 당신이 코드 밀도에 관심이 없다면 말이다.
image_view.jpg
코드 밀도
많은 임베디드 설계자들은 마이크로프로세서보다 시스템 내의 RAM과 ROM에 더 많은 비용을 소비한다. 메모리는 많은 시스템의 특성을 정의(또는 한정)한다. 마케팅은 메모리에 비용을 더 쓰기보다는 기능을 줄이고 싶어한다. 프로그래머는 메모리 예산에 코드를 맞추어야 한다.
이러한 면에서 코드 밀도는 큰 문제가 될 수 있다. 코드 밀도는 실행 가능한 프로그램이 얼마나 꽉 차 있는 지를 보여준다. 그것은 프로그램의 풋프린트이며 하나의 프로세서에서 다른 프로세서로 완전히 변한다. 이것을 경험해 보지 못했다면 당신은 컴파일된 C 프로그램은 모두 다 똑같고 어떤 칩이 실제 코드를 실행시키는 지는 중요하지 않다고 생각할 수도 있을 것이다. 이것은 큰 오산이다.
다른 칩을 위해 컴파일된 아주 똑같은 C 프로그램은 완전히 다른 메모리 풋프린트를 만들어낸다. 이것은 컴파일러의 실수나 오류가 아니다. 그것은 다른 칩보다 더 밀도가 높은 바이너리를 생산하는 몇몇 CPU 칩의 자연스런 특성이다.
그림 1은 많이 사용되고 있는 32비트 마이크로프로세서들의 코드 밀도 비교한 것이다. 그림에서 볼 수 있듯이, 차이는 절반까지 생길 수 있다. 이러한 칩들이 실제 같은 프로그램(같은 소스 코드)을 실행하고 있고 같은 결과를 가져온다고 해도 어떤 칩은 다른 칩 코드 공간의 반만 있으면 된다는 것이다.
CISC 칩의 코드 밀도가 RISC 칩의 코드 밀도보다 더 좋다는 것도 알 수 있다. RISC의 원칙 중의 하나는 모든 복잡한 기능은 다 소프트웨어에서 행해지고 하드웨어는 단순화되어야 한다는 것이다. 이는 RISC 칩이 같은 일을 하기 위해 CISC 칩보다 더 많은 소프트웨어를 필요로 할 것이라는 것을 의미한다. 대부분의 RISC 칩은 나누기 명령이 없다. 만약, 두 숫자를 나누길 원한다면 소프트웨어에서 하면 되는 것이다.
이에 대해 당신이 코드나 컴파일러에서 할 일은 없다. 컴파일러는 주어진 하드웨어 명령과 함께 일해야만 한다. 당신의 프로세서에 축약형 명령어가 있다면 컴파일러는 더 많은 소프트웨어를 만들어냄으로써 그것을 보상해 줄 것이다.

코드 압축
CISC 칩이 더 나은 코드 밀도를 가지고 있는 또 다른 이유는 그 명령이 짧아지는 경향이 있기 때문이다. 정의에 의하면, 32비트 RISC 칩은 32비트 명령을 가지고 있다. 반면 32비트 CISC 칩은 아마도 8비트, 16비트, 32비트 그리고 심지어 더 큰 명령을 갖게 될 것이다. 이것은 CISC 칩을 복잡하게 만드는 기능 중의 하나 이지만 임베디드 시스템 내에서는 더 효율적으로 만들기도 한다.
왜 당신은 명령 비트에 신경을 쓰는가? 예를 들어, 68020은 ADD 명령을 8비트 프로그램 메모리에 맞출 수 있지만 MIPS R4000은 32비트를 필요로 하기 때문에 프로그램이 두 개의 숫자를 같이 더할 때마다 이전 메모리의 3/4를 버리게 된다. 또한 MIPS 칩은 68K보다 빠른 것은 첨가할 수 없다.
최근 몇몇 RISC 벤더는 이 문제에 대한 현명한 해결책을 발견했다. 일반적으로 그 해결책은 코드 압축(code compression)이라 불리지만, 그것은 잘못된 이름이다. 아무도 PKZIP을 이용해서 코드를 압축하지 않는다. 대신에 그들은 칩의 명령 셋을 약간 바꾸어 모든 명령이 32비트 길이가 되지 않도록 한다.
이에 대한 세 가지 예가 ARM, ARC Cores 그리고 MIPS이다. 이들은 각각 Thumb, ARCompact, MIPS-16이라 불리는 비슷한 코드 압축 설계가 있다. 세 경우 모두 칩이 소수의 16비트 명령으로 그들의 32비트 명령 집합을 선택적으로 증대시킬 수 있다. 각각의 C 컴파일러는 이제 바이너리를 더 작게 만들면서 16비트 명령을 코드에 뿌릴 수 있다.
얼마나 더 작아지는 지는 여러 요인에 따라 다르다. 그리고 이미 알고 있는 바와 같이 마케팅 광고만큼은 힘들다. 실제 테스트에서 축소는 대략 20∼30% 정도이고 프로그램에 따라 다르다. 그것은 단지 코드 공간의 압축일 뿐이라는 것을 명심하라. 데이터 스토리지는 압축되지 않는다. 하지만, 코드 압축은 올바른 진보이며 RISC 아키텍처를 더욱 매력적으로 만드는 요인 중의 하나이다.
ARM Thum과 MIPS MIPS-16의 두 경우에, 당신의 코드는 32비트 모드와 16비트 모드 사이에서 확실히 스위치되어야 한다. 두 개의 명령형을 혼합할 수 없기 때문에 당신은 32비트의 명령을 사용하여 구동하는 코드에서 16비트의 동작과 함께 구동하는 코드를 분리해야 한다. 우선, 전적으로 16비트 명령과 함께 구동하는 코드 영역을 찾아야 한다.
더 짧은 명령을 위한 trade-off는 그들의 제한된 레퍼터리(repertoire)이다. 예를 들어, 16비트 코드는 인터럽트, 캐시 관리, 메모리 관리, 제외(exception) 또는 롱 점프(long jump) 등을 처리할 수 없다. 운 좋게도 Thumb와 MIPS-16 컴파일러는 이를 분류한다. ARC의 ARCompact는 두 모드 사이에서 스위치하지 않기 때문에 이 제한을 받지 않으며, 두 사이즈의 명령을 자유롭게 혼합하기 때문에 프로그램을 분리시키려고 애쓰지 않아도 된다.
IBM에서 나온 CodePack system은 임베디드 PowerPC 칩에 또 다른 방식으로 접근한다. 다른 세 개의 압축 RISC 명령어와는 달리, IBM은 PKZIP을 사용하는 것처럼 오브젝트 코드(object code)에서 실제로 실행 바이너리들을 압축한다. 이 때 컴파일되고 어셈블되고 링크된 후에 프로그램을 압축할 수 있다. 그리고 나서 압축된 것을 ROM이나 디스크에 저장한다.
임베디드 PowerPC 칩은 메모리로부터 패치될 때 명령을 푸는 별도의 하드웨어가 있다. 그림 2는 어떻게 각각의 명령이 풀리고 압축되는 지 보여준다.
첫째, 당신의 코드는 보통 오브젝트 코드 형식에서 저장되지 않았기 때문에 완전히 불가사의하다. 그 코드는 압축되었고 그것이 압축 해제를 어렵게 만든다. 코드를 보호해야 할 필요성이 있을 때엔 이것이 장점으로 작용할 것이다. CodePack은 소프트웨어를 압축해줄 뿐만 아니라 효과적으로 엔코드 해준다.
둘째, CodePack은 fly 상에서 소프트웨어를 풀어야 하는데, 그것은 가끔 보통 예상하는 것보다 시간이 오래 걸리기 때문에 재미있는 기능을 수행하기도 한다. CodePack이 장착된 PowerPC 프로세서는 branch와 jump을 처리하기가 까다로운데, 이는 branch target이 ROM에 놓여진 코드의 커다란 블록의 어딘가에 엔코드 되었을 때 위치를 정하기 어렵기 때문이다.
셋째, 각각의 CodePack 프로그램은 자신만의 압축키를 사용하기 때문에 프로그램이 다르면 압축도 다르게 된다. 이는 압축된 바이너리들이 양립할 수 없음을 의미한다. 따라서, 키가 없으면 다른 PowerPC에서 가동되지 않을 것이다.
마지막으로, CodePack은 ARC, ARM, MIPS와 똑같은 30%의 compression factor를 보증한다. 그 모든 복잡성을 감안한다면 두드러지게 좋아진 것은 아니다. 하지만, IBM은 획기적인 일을 해냈다.

RISC POWER
RISC 칩이 가지고 있는 하나의 장점은 전력소모량이다. 대개 RISC 칩은 CISC 칩보다 전력을 덜 소모한다. 이것은 명백하다. 만약 RISC 프로세서의 회로 설계가 더 단순하고 간소화되었다면 그것이 전력을 덜 소모하는 이유가 되었을 것이다. 트랜지스터가 더 적다는 것은 에너지가 덜 확장된다는 것을 의미한다.
ARM 프로세서는 전력을 적게 소모하기로 유명한데, 애석하게도 진실이 아니다. 물론 ARM 프로세서는 인텔의 486보다야 전력을 덜 소모하지만, 그것은 Hoover 댐도 마찬가지이다.
공정하게 말해서 ARM 프로세서는 전력을 덜 소모하는 편이긴 하지만, 같은 시기에 나온 대부분의 RISC 프로세서도 다 마찬가지이다. 1994년의 다른 프로세서와 비교하면 ARM7은 경이로울 만큼 전력효율이 높지만 2002년에는 많은 RISC 프로세서가 있을 것이다. 심지어 어떤 CISC 프로세서는 전력효율이 ARM보다 높다. MIPS, SuperH, ARC Core 그리고 다른 것들도 모두 저전력 코어를 가지고 있다.
RISC의 전력 상의 이점은 자동온도조절기(thermostat)나 휴대전화기, 스마트카드 등을 만들 경우에는 무척 중요하지만, 그 외의 다른 애플리케이션에서는 그다지 중요치 않다. 첫 번째 카테고리를 위해 RISC 프로세서는 좋은 선택이다. 비록 당신이 메모리 전력을 소비해도 좋지만, 당신은 CPU 전력을 절약해야 하는 바 조심해야 한다.
코드 밀도는 전력소모에 관계하기 때문에 코드 밀도가 더 나은 칩은 전체적으로 메모리 액세스를 많이 만들지 않아 시스템 전력을 덜 소모할 것이다.
ROM으로부터의 패치나 RAM으로의 읽기/쓰기 액세스는 전력을 적게 소모한다. 그것을 최소화할수록 더 좋다. 여기에는 확고한 법칙이 없기 때문에 예를 든다면 코드 밀도가 2배 증가하였다고 하여도 전력도 2배 증가한다고 말할 수 없다. 애플리케이션마다 다르지만, 만일 당신이 전력소모에 대한 압박을 받게 된다면 이 관계를 기억해라.

성능
RISC의 주요 이점 중에 하나가 그 탁월한 성능이고 따라서 RISC 칩은 항상 빠르다고 할 수 있을까? 한마디로 대답은 "아니오"이다.
무엇보다도 성능이란 말은 애매 모호한 표현이다. 모든 사람은 각각 다른 종류의 성능에 관심이 있다. 예를 들어 미디어 프로세싱에 좋은 것이 네트워크 프로세싱에는 좋지 않을 수 있다. 모든 것에 뛰어난 프로세서는 없다고 말해두겠다. 모든 CPU 명령 셋은 절충일 뿐이다.
당신은 당신의 특수한 애플리케이션에 맞는 ISA(Instruction Set Architecture)가 있는 CPU를 선택해야 한다. 같은 속도로 가동되는 두 개의 칩(여기선 100 MHz라고 하자)은 ISA의 차이에 의해 완전히 다른 성능을 제공할 수 있다.
대부분의 RISC 명령 셋은 거의 동일하다. 그렇다면 결국 그들은 아주 기본적인 것만을 지원하도록 되어 있었던 것인가? 실제 모든 RISC 아키텍처는 수년간 RISC 원칙을 따르지 않는 변형된 기능에 의해 타락해 왔다. 하지만, RISC 칩은 포괄적이고 호환성이 있다.
CISC 진영에는 시스템에 믿을 수 없을 만큼 유용하거나 시스템과 전혀 관련이 없는 여러 가지 명령들이 있다. 때론 어디서 이렇게 괴상한 명령이 나왔을까 생각되기도 하고 다른 프로그램은 이것을 어디다 쓸까 하고 의아해질 때도 있다.
그 중 내가 가장 좋아하는 것 중의 하나는 모토로라에서 나온 68300 제품군 칩에서 발견된 TBLS 명령이다. TBLS는 table look up이고 interpolate instruction이다. 대부분의 프로그래머는 그것을 절대 사용하지 않겠지만, 이런 명령이 필요할 경우 이것은 그야말로 구세주이다.
TBLS 명령은 데이터 포인트의 스파스 테이블(sparse table)에서 복잡한 기하학 함수(geometric function)를 만들 수 있게 해준다. TBLS는 당신이 만들어 놓은 값의 테이블을 탐색해서 가장 가까운 두 개를 당신이 지정한 숫자에 위치시킨다. 그리고 나서 linear interpolation을 통해 그 두 데이터 포인트 사이의 정확한 값을 계산한다. 본질적으로 TBLS는 그림 3에서 보는 것과 같이 X, Y분산그래프의 점들을 연결시킨다.
이상해 보이는가? 그럴 수도 있다. 하지만, 만약 당신이 동작제어를 하고 있다면, 이것은 무척 긴요하게 쓰일 것이다. 이게 없다면 모든 종류의 exception과 boundary case를 가지고 수백 개의 다른 기하학 함수를 코드해야 한다. TBLS는 약 30 클록 사이클에서 실행되는 단일 명령이란 것을 명심해라.

RISC 대 CISC
한마디로 RISC는 빠른 클록 속도를 얻기 위해 feature와 function을 포기하는 것을 의미한다. 당신이 속도를 숭배하고 클록 속도야말로 당신의 모든 것이라고 생각한다면 RISC가 적격이다. 당신은 200 MHz RISC 프로세서를 이용해 75 MHz clunker를 이용하는 것보다 더 높은 clock rate를 얻을 수 있다.
그러나, 더 나은 성능을 얻을 수 없게 되거나 비용만 많이 들이게 될 수도 있다. 빠른 프로세서는 빠른 RAM, 빠른 ROM, 빠른 I/O를 원한다. 당신의 전체 버스 구조도 더 빨라져야 할 것이다.
RISC에 특별한 명성이 있다는 점을 부인할 수 없다. 그것은 새롭고 흥미로운 것으로 인식되고 있으며, 아직도 CISC 프로세서가 강세라는 의견은 반 직관적으로 보인다. 그럼에도 불구하고, CISC는 많은 장점들을 가지고 있다. 코드 밀도와 집적이 더 좋으며, 비트 조작, 메모리 액세스, looping, decision tree 등을 위한 특수한 명령의 성능이 뛰어나다. RISC는 어떤 추상적인 우아함이 있지만, 이것은 비즈니스에는 소용이 없다. 때로는 느리고 꾸준한 것이 경기에서 승리할 수 있다.

'Programming > Linux embedded' 카테고리의 다른 글

glut 크로스 컴파일하기  (0) 2008.08.22
ARToolKit MRP-S3C2440(REBIS)용으로 포팅하기 2부(삽질성과 1호!!!) -미완  (0) 2008.07.10
ARToolKit MRP-S3C2440(REBIS)용으로 포팅하기 1부(삽질성과 1호!!!)  (0) 2008.07.10
도대체 크로스 컴파일러 툴 체인 이란 무엇인가?(2) - 유 영 창  (0) 2008.05.21
도대체 크로스 컴파일러 툴 체인 이란 무엇인가?(1) -유영창  (0) 2008.05.21

+ Recent posts

티스토리툴바