지난 글에서 CPU의 명령어를 알아보았다. 메모리에 명령어가 준비되었으니, 이제 CPU가 이를 어떻게 실행하는지 살펴보자.
CPU가 명령어를 처리하려면 무엇을 해야 할까? 메모리에서 명령어를 가져오고 (Fetch), 그 의미를 해석하고(Decode), 해석한 대로 실행(Execute)한다. 이 세 단계를 끊임없이 반복하는 것이 CPU가 하는 일의 전부다.
메모리에는 명령어가 여러 개 저장되어 있다. CPU는 어디서부터 가져와야 할까?
책을 읽을 때 손가락으로 줄을 짚듯이, CPU에도 지금 어디를 읽고 있는지 가리키는 장치가 있다. Program Counter(PC)라는 레지스터다. CPU는 PC가 가리키는 주소에서 명령어를 읽어온 뒤, PC를 다음 주소로 한 칸 옮긴다.
보통 PC는 한 칸씩 순서대로 증가하지만, 지난 글에서 본 JUMP와 JZ 명령어는 PC를 직접 바꿔 반복문이나 조건 분기를 가능하게 한다.
| 주소 | 이진수 | 어셈블리 |
|---|---|---|
| 0 | 01100001 | LDI R0, 1 |
| 1 | 01100110 | LDI R1, 2 |
| 2 | 00010001 | ADD R0, R1 |
| 3 | 10010101 | STORE 5 |
| 4 | 11000010 | JUMP 2 |
| 5 | 00000000 | 데이터 |
가져온 명령어는 01100011 같은 이진수일 뿐이다. 이걸 어떻게 해석할까?
이 시리즈의 8비트 ISA에서는 명령어를 두 부분으로 나눠서 해석한다. 앞 4비트는
opcode, 즉 무엇을 하라는 명령이다. 뒤 4비트는 operand, 즉
어디에/무엇에 대해라는 대상이다. 예를 들어 0110 0011이면 opcode
0110(LDI)에 operand 0011(레지스터와 값)이므로, 레지스터에 값을
저장하라는 뜻이 된다.
이 해석을 담당하는 것이 제어 장치다. 제어 장치의 핵심은 앞서 배운 디코더와 MUX다.
opcode 4비트가 디코더에 들어가면, 해당 명령어에 대응하는 제어 신호 하나만
활성화된다. 예를 들어 opcode가 0110(LDI)이면 레지스터에 값을 쓰라는 신호가
켜지고, 0001(ADD)이면 ALU로 덧셈하라는 신호가 켜진다. 나머지 신호는 모두
꺼진 상태다.
operand 쪽도 비슷하다. 명령어에 레지스터 번호(2비트)가 포함되어 있으면, 그 번호가 MUX의 선택 신호가 되어 네 개의 레지스터 중 하나를 골라 읽거나 쓴다.
즉시값을 Rd에 로드한다.
제어 장치가 신호를 보내면 실제 연산이 수행된다. 예를 들어 ADD R0, R1이라면,
제어 장치가 ALU에 덧셈 신호를 보내고 MUX가 R0과 R1의 값을 선택한다. ALU가 두
값을 더한 결과가 R0에 저장되고 Zero Flag가 갱신된다.
지난 글에서 본 연산 명령어(ADD, SUB 등)는 ALU에서,
데이터 이동 명령어(LOAD, STORE 등)는 레지스터와 메모리 사이에서 실행된다. 실행이
끝나면 PC가 다음 주소로 증가하고, 다시 Fetch로 돌아간다.
이 부품들을 하나로 조립한 폰 노이만 시뮬레이터에서 Fetch-Decode-Execute 사이클을 한 단계씩 실행해보자.
0과 1에서 시작해 논리 게이트, 가산기, 래치, 튜링 머신, 폰 노이만 구조를 거쳐 동작하는 컴퓨터를 조립했다.
그런데 한 가지 문제가 있다. 오늘날 CPU는 1초에 수십억 개의 명령어를 처리할 수 있지만, 메모리에서 데이터를 가져오는 속도는 이에 비해 수백 배 느리다. Fetch 단계에서 매번 메모리에 접근해야 하니, CPU가 아무리 빨라도 메모리를 기다리는 시간이 병목이 된다. 다음 글에서는 이 속도 차이를 어떻게 해결하는지 살펴보자.