컴퓨팅 기술의 원형 탐험 Part 3: 폰 노이만과 프로그램 내장식 컴퓨터

안윤호 mindengine@freechal.com 필자는 아마추어 리눅스 커널 해커였으며 최근에 팹(Fab)이라는 책을 번역 출간했다. 컴퓨터의 여러 분야에 관심이 많고 컴퓨터와 문화의 인터페이스에도 관심이 많다 2008년 5월 20일

연재순서
1회(2008년 3월): 간단한 레지스터 머신에서 시작해 보기
2회(2008년 4월): 작은 아이디어가 만들어낸 큰 차이
3회(2008년 5월): 폰 노이만과 프로그램 내장식 컴퓨터

시퀀셜 머신에서 컴퓨터로

1945년에 작성된 ‘First Draft of a Report on the EDVAC’이라는 유명한 글이 있다. 이른바 폰 노이만(John von Neumann) 아키텍처라고 부르는, 오늘날의 컴퓨터의 기본적 동작을 정의한 글로 처음에 손으로 쓴 글을 다시 타이핑한 것이다(글은 인터넷에서 PDF 형태로 읽어 볼 수 있다).

노이만은 원자폭탄, 컴퓨터, 미사일 개발에서 핵심 두뇌 중의 두뇌였다. 핵 개발이 끝나자 노이만은 ENIAC(Electronic Numerical Integrator and Calculator, 이하 에니악)을 만든 펜실베이니아 대학에 눌러 앉았다. 에니악은 1946년 펜실베이니아 대학에서 대중에게 알려졌는데 개발은 더 일찌감치 이루어졌다. 첫 번째 계산은 대포의 사정거리표가 아니라 로스알라모스의 핵폭탄 개발의 수학적 모델링을 위해 사용되었다. 이 계산은 폰 노이만이 이끌어냈다고 전한다. 혹자는 폰 노이만을 컴퓨터에 관심을 갖게 만든 것이 아마 에니악의 가장 중요한 귀결일 것이라고도 말한다. 노이만은 핵무기와 컴퓨터, 나중에는 장거리 미사일 개발에 관여한다. 대륙간 탄도탄 위원회는 폰 노이만 위원회라고도 불렀다.

수학 신동이었으며 한때 처치나 튜링과 같이 있던 적도 있던 폰 노이만은 정부에도 영향력이 강한 조언자였다. 노이만은 대포의 사정거리표 같은 것보다 훨씬 더 많은 것을 에니악이 계산할 수 있음을 실감하고 있었다. 에니악은 다소 둔한 최초의 프로그램 가능한 전자식 디지털 계산기였다. 무게는 가볍게(?) 30톤이 넘고 최고의 속도를 얻기 위해 배선반에서 프로그램 되었으며 프로그램 재작성에는 며칠이 걸렸다. 프로그램 가능하다고 보는 것은 관대한 편이다. 그러나 이 컴퓨터의 경험으로 노이만은 1945년 육군 조달부에 EDVAC(Electronic Discrete Variable Computer, 이하 에드박) 제안서를 냈으며 1946년 아이디어를 더 발전시킨 메모를 적었다. ‘Preliminary Discussion of the Logic Design of an Electronic Computing Instrument’라는 제목이었다.

1945년의 ‘First Draft…’에서 시퀀셜 머신의 제어기는 변화를 암시하기 시작한다. 이 글이 사람들에게 회람되자 펜실베이니아 대학의 디자인팀은 반발했다. 대중에게 알려지면 나중에 특허를 내는 데 지장이 생길 뿐 아니라 프로그램 내장식 컴퓨터는 노이만 혼자의 아이디어가 아니라 학교의 무어(Alfred Moore) 연구소의 토론에서 도출됐다는 이유에서였다. 무어 연구소는 디지털 회로와 컴퓨터의 중요한 혁신이 일어난 장소다. 디지털 제어기와 시퀀스 로직의 중요한 연구 성과가 이미 이루어진 상태에서 노이만이 컨설턴트 자격으로 눌러앉아 토론에 참여했다. 이곳에서 에니악과 에드박이 나왔고 이 연구소의 개발자였던 모클리(John Mauchly)와 에커트(J. Presper Eckert)가 최초의 상업적 컴퓨터 회사 UNIVAC을 만들었다.

프로그램 내장식으로 가는 진화의 첫 단계는 제어기를 만드는 일에서 출발한다. 단순한 논리 회로에서 프로세서로 이행하는 진화의 결정적인 요소는 제어 유닛(Control Unit) 도입이었다. 그림 1은 1970년대 프로세서 설계에 대해 적은 책의 일부다(이 그림은 1971년 발행된 Gordon Bell과 Alan Newell의 ‘Computer Structure: Reading and Examples’에서 원용된 것으로 추정된다).

위로

간단한 프로그램이 제어 유닛에 내장되어 있었고 제어 유닛 그 자체는 위에서 설명한 간단한 카운터와 같은 구조다. N1과 N2는 레지스터가 없는 단순한 논리 회로 그 자체다(AND OR NOT의 조합으로 만들 수 있다). 그리고 제어 유닛은 미리 정한 신호 s1, s2, s3를 N1과 N2로 보낸다.

N1에서는 s1 신호가 들어오면 그림의 입력 X 값이 B로 들어간다(B <- X). N2에서는 s1에서는 아무 일도 하지 않으나 s2 신호가 들어오면 A<-B, C<-[0]의 조작을 하게 된다. s3에서는 A <- A+B, C <- A와 B의 오버플로우를 출력하도록 설정한다. 제어 유닛은 클럭이 들어가면 s1, s2, s3의 제어 신호를 내고 종료한다. 시스템에서 s1과 s2, s3의 의미는 아래와 같다.

* s1: B<-X
* s2: A<-B, C<-[0]
* s1: B<-X
* s3: A<-A+B, C<-오버플로우가 일어나면 C 비트가 세트된다. 
  

결과는 문제없이 동작하는 범용의 덧셈 장치라고 할 수 있다. 제어 유닛의 동작은 아주 간단하다.

CU: 
(output s1)
(output s2)
(output s1)
(output s3)
end
  

N2가 계산 장치인 ALU(Arithmetic Logic Unit) 역할을, 레지스터 A가 accumulator 비슷한 역할을 하는 것인데 CU와 N1, N2를 다른 세트로 교체한다면 뺄셈을 할 수도 있고 곱셈을 할 수도 있으며 시프트 연산이나 다른 일들도 할 수 있다. 실제로 DEC(Digital Equipment Corporation)는 제어 유닛과 ALU 같은 것들을 IC가 아니라 트랜지스터로 직접 제작하고 팔기도 했다.

동작을 정의하고 보니 일종의 프로세서라는 것이 별로 대단한 것이 아님을 알 수 있다. 당시 무어의 연구소에서는 이런 작업들을 연구하고 있었다. 요즘 학생들이 디지털 실습 시간에 하는 실험들은 당시 무어 연구소의 심각한 도전이었던 셈이다. 그리고 위의 제어기는 지난번에 적었던 간단한 프로그램, 즉 롬의 테이블을 그대로 프로그램으로 옮긴 것 같은 프로그램의 조직론이 무어 연구소의 중요한 과제였다.

그러나 몇 단계가 더 남아 있었다. 그 다음의 결정적인 진화는 명령어 처리기를 가지고 제어 유닛을 마음대로 제어하는 이른바 프로그램 내장식 컴퓨터로 진화하는 것이다. 별것이 아니다. 그림 2에서 보면 I라고 적힌 인스트럭션 레지스터(Instruction Register)가 있다. 이 I 값에 따라 더하기, 빼기, 곱하기, 시프트 연산을 하도록 제어 유닛을 조금 더 복잡하게 만든다. 그러니까 커다란 변화라는 것은 제어기를 제어하는 제어기의 추가라고 생각하면 된다. 몇 개의 제어기를 만들고 이것들을 제어하는 제어기를 만드는 것이다. 효율을 너무 따지지 않으면 머릿속에서 만들고 연필로 그린 다음 프로그램으로 옮겨서 테스트해볼 수 있다.

위로

제어 유닛에 들어 있는 레지스터를 제외하면 밖에 나와 있는 레지스터는 A, B, I 세 개뿐이다. 나중에 오버플로우를 표시하는 1비트의 레지스터는 상태 레지스터로 진화할지도 모르니 네 개라고 치자. 지나칠 만큼 간단하지만 초창기 컴퓨터는 복잡할 수가 없었다. 복잡하게 설계할 여력도 지식도 없었던 것이다.

그렇다면 명령어 레지스터 I의 값에 따라 제어 유닛의 기능이 변하는 논리 회로가 바로 컴퓨터의 전신이다. 명령어 몇 개로 중요한 처리를 다 할 수 있는 간단한 프로세서의 원형이 나온 것이다. 여기다 몇 개의 데이터패스만 더 추가하면 컴퓨터가 된다. 이제 명령(instruction)은 회로 안에 있는 것이 아니라 I 레지스터의 값에 좌우된다. 프로세서는 I 값에 정해진 동작만을 수행한다.

이 정도가 되면 휴대용 계산기 수준이다. 실제로는 작은 휴대용 계산기의 내부 역시 아주 간단하지는 않다. 휴대용 계산기의 I 값은 * + - / 버튼 가운데 하나가 될 것이다. 이 버튼을 누르는 것이 바로 명령이다! 실제로 간단한 전자 계산기의 초기 회로는 미니컴퓨터와 많이 닮았고 잘 나가던 일본의 계산기 회사 비지콤이 인텔에 주문한 칩이 최초의 마이크로프로세서가 되었다.

앞에서 설명한 유사 코드와 시퀀스 로직을 합치면 아마 독자들은 이 계산기를 돌릴 수 있는 코드를 어떻게든 만들어 낼 수 있을 것이다. 종이와 연필로 신호선을 그리고 코드로 옮기면 된다. 중요한 것은 아무리 엉성해도 조금만 생각하면 돌아갈 수 있는 프로세서 비슷한 것을 만들 수 있다는 사실이다. 효율은 나중에 고민할 일이다.

그 다음에 다시 진화가 일어났다. 제어 유닛은 명령어를 외부에서 가져올 수 있도록 새로운 제어 루프를 만든다. 제어 유닛은 리셋이 걸리고 난 초기 상태에서 시작할 명령이라는 것을 가지고 와야 한다. 그리고 명령에는 특정한 값이 필요할 것이다. 데이터패스도 추가되어야 한다. 적어도 명령을 읽어 들이는 일에는 외부 기억장치가 필요하고 보통 이 기억장치 역시 메모리에 들어있으므로 메모리 위치인 어드레스와 데이터 값을 읽기 위한 신호선이 필요하다. 이 신호를 앞의 프로그램에 추가한다. 제어 유닛은 명령어를 밖에서 읽어 들인 후 이 명령어를 수행한다. 그리고 필요한 데이터와 어드레스를 입출력한다. 명령을 수행하고 나면 그 다음 불러올 번지를 계산하여 어드레스 신호를 내야 한다. 그러려면 PC(Program Counter)와 같은 구조가 필요하게 된다. 이런 식으로 몇 가지를 추가하면 자체 완결적인 프로세서가 되는 것이다. 계산을 하거나 하지 않는 것도 필요하지만 중요한 사실은 외부의 명령어를 읽어 그것을 수행하는 하나의 완결적인 제어 메커니즘을 갖게 되었다는 점이다.

이런 방식이 일단 발명되자 다음은 모두 비슷한 패턴으로 만들어졌으니 컴퓨터는 폰 노이만 방식 비슷하게 부팅했다고 볼 수 있다. 사실은 사람들의 아이디어의 부팅까지가 어려운 과정이었다. 어마어마한 양의 지적인 에너지와 당시로서는 많은 금액이 투자되었다. 에니악 초기 개발에는 작은 발전소의 전기를 모두 소모할 정도였다는 일화가 있다. 진공관 1만 8000개를 구동하려면 전력 소모가 발전소까지 가지는 않더라도 변전소 하나는 있어야 할 정도였다. 더군다나 당시는 전쟁을 하던 시절이었다.

일단 만들어지고 나니 명령어를 만들고 어셈블러도 만들었으며 컴파일러와 여러 가지 도구가 만들어지는 것은 시간 문제였다. 어셈블러를 만들 때의 재미있는 일화가 하나 있다. 폰 노이만이 반대를 한 것이다. 이런 쓸데 없는 작업으로 컴퓨터의 연산능력을 낭비하면 안 된다는 것이었다. 노이만은 기계어를 더 좋아했다. 그리고 기계어만으로 충분히 무슨 일이나 할 수 있을 정도로 머리가 좋았다. 그러나 사람들은 그렇지 않았기 때문에 컴퓨터 언어를 쓰는 편이 더 좋았다. 그 다음에 노이만은 최초의 고급 언어라고 할 수 있는 포트란에 대해서도 쓸데 없는 일을 한다고 비평했다. 그러나 포트란은 컴퓨터 사용을 대폭 확장하는 길을 열었다. 노이만이 탁월하기는 했으나 항상 그의 의견이 옳았다고 할 수는 없었다.

일단 무엇인가가 만들어지자 만든 사람들과 사용하는 사람들은 다른 길을 갈 수 밖에 없었다. 컴퓨터는 아무것도 없는 상태에서 많은 에너지 투입을 거쳐 만들어진 후 점차 사람들의 손으로 넘겨졌다. 에드박 정도가 나오자 여기저기서 자신들의 버전을 만드는 사람이 늘어났다. 가장 어려운 일은 아무것도 없던 상태에서 I 레지스터의 제어 구조를 만드는 일까지로 교과서에서는 프로그램 내장식 컴퓨터라고 한 줄로 줄여 말한다. 그러나 그전에 유한 상태 기계와 시퀀셜 제어기 시절을 거쳤고 그 중에서 나온 하나의 발전, 조금 특별한 시퀀셜 제어기라는 사실을 잊어서는 안 된다.

I 레지스터에 들어가 컴퓨터를 제어할 데이터이자 프로그램의 요소인 명령어 구조는 컴퓨터의 구조와 뗄 수 없는 구조를 가지고 있으니 가장 간단한 프로세서를 들여다보는 편이 이해가 빠를 것 같다.

위로

비교적 간단한 프로세서 MU0 맛보기

필자의 원래 의도는 마이크로프로세서의 모태가 되었던 PDP-8의 구조를 도해하려는 것이었으나 워낙 오래된 프로세서라 독자들이 실감하지 못할지도 모른다는 생각이 들었다. 그 대신 S. Furber의 ARM 교과서에 잠깐 소개되는 MU0에 대해 살펴보려 한다.

앞에서 설명한 프로그램을 그대로 플립플롭과 플래시 롬 같은 것으로 대체한다고 해도 실제로 동작은 가능하다. 프로그램을 그대로 롬 테이블에 집어 넣는 것으로 복잡한 게이트 설계를 대체할 수 있기 때문이다. 이런 롬과 몇 개의 플립플롭 레지스터나 램이 준비되고 미리 만들어진 ALU 유닛 같은 것을 이용하면 사실상 원리적인 프로세서는 곧바로 만들 수 있다. 레지스터와 연산 유닛 세트와 데이터가 전달되는 신호선 같은 것을 데이터패스라고 부르며 이것들을 제어하는 로직은 제어 로직(앞서 설명한 제어 유닛과 같다)이라고 부를 수 있다.

한국어판으로도 번역된 Furber의 책에 나오는 간단한 프로세서 MU0는 매우 간단한 마이크로프로세서다. 그리고 아마도 프로세서를 가장 간단히 설계한다고 해도 비슷한 모양이 될 것이다. 그림 3은 간단한 명령어 구조를 보여준다. 16비트 중 4비트를 연산 구분에 사용한다. 그림 4는 데이터패스의 구조다.

옵코드 명령어 동작은 다음과 같다.

0000 LDA S ACC := mem16[S]
0001 STO S mem16[S] := ACC
0010 ADD S ACC := ACC + mem16[S]
0011 SUB S ACC := ACC - mem16[S]
0100 JMP S PC := S
0101 JGE S if Great or Equal PC := S
0110 JNE S if Negative PC := S
0111 STP stop

이 정도로도 많은 일을 할 수 있다. 간단한 계산을 할 수도 있고 원하는 데이터를 메모리에서 가져올 수도 있으며 다음에 가져올 명령어의 메모리 번지를 새로 계산할 수도 있다. 이를테면 명령 0000은 ACC로 원하는 번지의 데이터를 옮기는 옵코드로 정할 수 있다. 0001은 그 반대로 더하기나 빼기를 만들 수도 있다. 조건부 브랜치 명령도 정할 수 있다. 이 정도면 간단한 코드를 만들 수도 있을 것이다. 그러나 명령어를 쓰다 보면 명령어의 옵코드가 4비트로 어쩌면 부족할지도 모른다는 것을 알게 된다. 아무리 RISC 비슷한 것을 만든다 해도 4비트는 너무 작은 공간이다. 그러면 8비트 프로세서처럼 바이트 여러 개로 명령어 하나를 만드는 방법도 나오게 된다. 복잡한 명령을 쓰는 CISC에서 여러 바이트 명령은 당연한 관행이었다.

이 프로세서의 데이터패스들이 하는 일은 우선 명령어를 메모리에서 가져오는 일이다. 그 다음은 메모리에서 명령어가 필요로 하는 데이터를 끄집어내오는 일이다. 이런 일에 필요한 데이터패스를 만들고 절차를 적어놓고 그때마다 필요한 제어 신호를 정한 다음 종이와 연필로 계산하거나 컴퓨터를 이용해 시뮬레이션한다. 종이와 연필로 신호선과 동작을 정하였다면 어려운 일이 없다. 컴퓨터로 시뮬레이션까지 마쳤다면 실제로도 문제가 없을 것이다. 이것이 바로 제어 로직(Control Logic)이 하는 일이다.

Furber의 책 ARM system-on-chip architecture(그림 5)는 이제 고전이 되었다. 책에 나오는 그림 1.6과 표 1.2가 이런 일을 하는 방법을 모두 요약한 것이다. 경우에 따라서 이 표만 보고 나서도 CPU 설계가 무엇을 의미하는지 깨닫는 독자들도 있을 것이다. 실제로 여기서 한 발짝 더 복잡한 것이 실제 프로세서다. 간단해 보이지만 많은 것을 배울 수 있는 예다. 책에는 무척 간략하게 나온다. 지나치기도 쉽다. 그러나 자세히 들여다보면 많은 것을 배울 수 있는 내용이 숨어 있다. 만약 관심이 있는 독자라면 Furber 책의 연습문제까지 풀어보기 바란다.

위로

필자가 지금까지 말한 내용과 Furber 책의 데이터패스와 제어 로직이 바로 튜링 시절부터 발전을 거듭해 온 프로세서의 구조다.

필자의 설명은 너무 이야기 같고 Furber의 책은 너무 단순하니 일종의 고전인 패터슨과 헤네시의 COD(Computer Organization and Design)를 읽어보는 것도 좋을 것이다. COD는 데이터패스와 제어 유닛의 동작 설명을 조금 더 자세하게 RISC에 맞춰 설명한다. COD가 좋은 교과서이긴 하지만 제어 로직의 복잡성이나 실제 구현을 보여주는 일에는 미흡하다. 그러나 이만한 교과서도 별로 없을 것이다. COD 저자의 홈페이지에는 보충하는 내용이 많이 (그리고 조금은 두서없이) 널려있다. 필자는 그 중간 정도의 교재 같은 것이 하나 있으면 좋겠다고 생각할 때가 있다. 입문용으로는 정말 요긴하게 쓰일 것으로 생각한다(필자에게는 T. Booth의 Digital Networks and Computer Systems(2/e)라는 책이 하나의 화두였는데 이미 30년 전 책이긴 하지만 정말 재미있게 읽었던 기억이 있다. 적어도 아마추어에게 구체적 통찰력을 주기에는 충분했다). COD는 실제 MIPS 칩의 데이터패스와 제어 유닛을 보여주므로 조금 어려우며 MU0는 실제성이 부족하다. 따라서 MU0와의 연관성을 생각하면서 COD의 해당되는 장을 읽고 있으면 무언가 떠오르는 것이 있을지도 모른다.

MU0가 훨씬 쉬우므로 논의의 대상으로 삼기로 하자. 책의 표 1.2에 나오는 내용은 롬으로 단번에 구현할 수 있다. 표를 그냥 옮기면 될 정도다. 이것들을 PLA(Programmable Logic Array)로 옮기는 것도 어렵지 않다.

MU0에 조금씩 명령어를 보태고 데이터패스의 요소들을 첨가하고 제어 로직을 조금씩 복잡하게 만들면 최소한도의 실용적인 복잡성에 도달한다고 할 수 있겠다. 여기까지의 작업은 1980년대의 작은 컴퓨터로도 충분히 검증해 볼 수 있는 내용이었고 실제로 ARM의 오리지널 설계팀은 처음에 8비트 컴퓨터에서 베이직으로 만든 도구로 검증 작업을 했다. 물론 ARM의 초기 형태라 해도 MU0보다는 훨씬 더 복잡했다(요즘 PC로 자바나 파이썬 같은 언어로 검증과 설계를 해보는 것은 당시의 슈퍼컴퓨터보다 좋은 장비를 쓰는 것이나 마찬가지다).

컴퓨터 개발의 일화를 두서없이 적어 본 내용을 생각하며 COD를 읽으면 조금 생각이 달라질지도 모른다. COD 다음에 하드웨어에 관심이 많은 개발자가 할 일이라는 것은 VHDL 같은 것으로 칩을 직접 만들어 보는 것이니 역사적인 맥락을 모두 잊어버리고 몇 개의 주어진 예제에 집착하게 된다. 그러나 이런 것들을 한번 종이와 연필로 적어 보거나 그려보는 일 역시 나름대로 중요하다. 통찰력이라는 것을 얻을 수 있는 경우가 많으니까.

아무튼 CPU나 프로세서 설계 방법과 명령어 체계를 알게 되자 프로세서는 전자회사들이 쉽게 만들 수 있는 대상으로 변했다. 컴퓨터와 논리 회로의 구분이 애매하던 시절에 DEC는 PDP라는 상품명으로 컴퓨터를 내놓았다. PDP는 Personalized Data Processors의 약자였는데 컴퓨터라는 이름을 붙이지 않은 것은 회사가 살아남기에는 시장이 너무 작아 보였기 때문이라고 한다.

PDP 시리즈가 공전의 히트작이 되고 시간이 흐르자 이런 종류의 컴퓨터를 미니컴퓨터라고 부르게 되었다. 그 다음에는 허니웰, GE 같은 회사들과 일본 회사들이 자신들의 컴퓨터를 출시했다. 명령어는 비슷한 것이 중복되게 정의되거나 불필요한 것도 많았으며 기계어 프로그램을 짜는 사람들과 시스템 엔지니어들도 잘 모르는 명령이 허다했다. 데이터패스를 설계해 놓은 것만 있으면 명령어는 제어 유닛을 바꾸어 놓기만 하면 되는 시절이 있었기 때문에 제어 유닛에 흔히 쓰이던 PROM만 바꾸면 다른 회사의 기계어를 그대로 사용해도 되던 시절도 있었다. 정말로 튜링 머신들(프로세서)들은 다 비슷했던 것이다. 한 컴퓨터가 하던 일들을 다른 컴퓨터가 할 수 있었다. 대형 또는 미니컴퓨터 시절에는 이런 일들이 흔했다. 요즘은 VM들이 이런 일을 한다.

마이크로프로세서가 나오기 전까지는 이런 관행이 계속되었다. 프로세서는 여러 가지 스타일로 만들 수 있었다. 제어 유닛과 데이터패스를 정의할 수 있다면 명령어를 만드는 것은 누구나 할 수 있는 일이다. SICP의 5장 레지스터 머신에 나오는 스킴칩은 아예 ALU를 사용하지도 않았다. 리스프 머신의 프로세서는 명령어를 리스프가 더 효율적으로 구현되게 CONS 연산 같은 것들이 편리하게 수행하도록 명령어 체계를 만들기도 했다.

다양성을 자랑하던 칩들이 서로 경쟁하다가 시장을 평정하는 마이크로프로세서들이 나타나자 사람들이 명령어를 정의하는 일은 점차 없어지고 프로세서의 이해라는 것이 인텔이나 모토로라의 프로세서 매뉴얼을 읽어야 하는 시절로 변해갔다. 요즘 칩들은 이해조차 어려운 부분이 많지만 그 시작은 의외로 단순하고 기계적인 내용이었다. 그 시작 뒤에는 아주 똑똑한 사람들의 통찰력이 숨어있다. 그것이 필자의 논점이기도 하다. 독자들이 똑똑해지지 않을 이유가 없다.

필자가 곧잘 예로 드는 사례로 TTL 계열의 IC를 이용해 프로세서를 만들어보았던 “A Minimal TTL Processor for Architecture Exploration”이라는 글이 있다. 구글에서 검색하면 문서들을 찾을 수 있을 것이다. 이 프로젝트는 간단한 TTL들을 이용하는 것으로도 프로세서를 만드는 일이 가능하다는 것을 보여주는 좋은 예이기도 하다. 회로까지 공개한 프로젝트라서 사용된 TTL들을 플래시 롬이나 PLD 같은 것으로 대체하면 더 간단한 프로젝트로 만들 수 있다는 것도 독자들은 이미 알고 있을 것이다. 아니면 비슷한 것을 더 원초적으로 만들어 볼 수도 있을 것이다(필자는 예전에 바이오스 칩에 쓰는 28f010 몇 개와 PLD로 며칠 동안 아주 느리고 간단한 CPU를 만든 적이 있다).

프로세서라는 것은 이처럼 간단하다. 여기에 가지를 치고 설비를 더한 것들이 요즘의 프로세서로 변한 것뿐이다. 그 진화의 경로도 결코 긴 시간에 걸쳐 일어난 것도 아니다. 그런데 요즘의 프로세서 매뉴얼을 보고 있으면 거의 이해를 포기시키려는 것처럼 보인다.

위로

mar.gar.in

naver

eolin

del.icio.us

[지난 Special Issue 보기]