2. 프로그램의 실행 과정 및 CPU 구조와 원리

---

- 프로그램 실행 과정 및 CPU 구조와 원리

목차

0. 파일 생성 흐름

1. 명령 주기

2. 구성

3. 설명

0. 파일 생성 흐름

---

실행파일 생성 흐름

- 전처리기 ^[각주:1] → 컴파일러 ^[각주:2] → 어셈블러 ^[각주:3] → 링커 ^[각주:4]

( ※ 어셈블리 코드 ^[각주:5] )

프로그램의 실행 과정

↓      cpu 부분의 처리, 상세.

1. 명령 주기

---

예외 처리를 추가한 간단한 CPU Instruction Cycle(명령주기)

2. 구성

---

 기본 구성으로는

•  레지스터 ^[각주:6]
•  프로그램 카운터 ^[각주:7]
•  명령어 레지스터 ^[각주:8]
•  산술논리연산장치(ALU: Arithmetic logic unit) ^[각주:9]
•  제어부 ^[각주:10]
•  내부 버스 ^[각주:11]

등이 있다.

이 외에도 캐시 같은 부가 장치도 들어가 있는 경우가 대다수.

3. 설명

---

 거의 모든 종류의 CPU가 하는 일은 요약해 보면 대부분 아래 4가지 기능이 전부다.

• Fetch (인출)
  - 메모리 상의 프로그램 카운터가 가르키는 명령어를 CPU로 인출하여 적재.
• Decode (해석)
  - 명령어의 해석. 이 단계에서 명령어의 종류와 타겟 등을 판단한다.
• Execute (실행)
  - 해석된 명령어에 따라 데이터에 대한 연산을 수행한다.
• Writeback (쓰기)
  - 명령어대로 처리 완료된 데이터를 메모리에 기록한다.

 위의 CPU 는 아주 초급적인 설명에 기반하며, 상용 CPU는 이런 간단한 구조만을 갖지는 않는다.

그나마 명령어의 실행 순서를 섞을 수 없는 Inorder CPU ^[각주:12] 를 엄청 단순화시키면 이 기능이 전부라고 우길수는 있을지도..?

 

 아무튼, 

명령어의 실행 순서를 섞을 수 있는 현대의 Out-of-order CPU 들은 아래와 같은 순서를 거쳐 명령어를 실행한다.

• Fetch ^[각주:13]
• Decode ^[각주:14]
• Rename ^[각주:15]
• Dispatch ^[각주:16]
• Issue ^[각주:17]
• Execute ^[각주:18]
• Writeback ^[각주:19]
• Commit ^[각주:20]

 그리고, Out-of-order CPU 를 만들기 위해서는, 위의 명령어 처리 과정 외에도 몇몇 핵심 기술들이 요구된다.

• Cache 
  - 주 메모리 값을 임시 저장하는 작고 빠른 메모리. 
  주 메모리 접근은 CPU입장에서 100사이클 정도 놀게 만드는 엄청나게 느린 동작이므로 Cache가 없으면 명령어를 
  빠르게 실행하고 싶어도 값이 준비가 안 돼서 불가능하다. 
  캐시 메모리도 한 개만 존재하는 것이 아니라, 보통 중요도와 접근 빈도에 따라 L1~L3의 3개 캐시 메모리를 사용하며, 
  숫자가 작을수록 용량이 더 작고, 더 빠르다. 
  또한 캐시 메모리만을 위한 색인 제조 방법과 구동방식은 해당 항목에서 확인 바람.
• Brabch predicition 
  - Fetch를 매 사이클마다 하기 위해선 다음에 실행할 명령어 주소를 알아야 하는데, branch 명령의 결과가 나오려면 
  꽤나 시간이 걸린다 (게다가 프로그램마다 차이는 있지만, 명령어의 약 30%정도는 branch이다.) 
  그러니 branch 명령의 결과를 과거의 기록을 기반으로 예측하는 기술이 필요하다
• Speculative memory disambiguation 
  -  메모리 접근 명령어들은 메모리 접근 전에 접근할 메모리 주소를 먼저 구해야 한다. 
  이 때문에 만약 LSQ에 Store 명령이 접근할 메모리 주소를 계산하기 위해 대기중이면, 
  이후 모든 Load 명령어는 접근할 메모리 주소가 준비되었다 하더라도 메모리 접근을 할 수 없다. 
  혹시라도 그 Store가 접근하는 주소가 Load가 접근하는 주소랑 같으면 가장 신선한 값은 메모리가 아니라 
  그 Store 명령어가 가지고 있기 때문이다.
  하지만 할 수 없는 걸 그냥 해버리면? (즉, Speculative memory disambiguation) 
  역시 Out-of-order CPU! Inorder CPU가 못하는 걸 태연하게 해버려! 거기에 동경하게 돼 
  대부분의 경우 접근하는 메모리 주소는 다르기 때문에 문제가 없으며, 문제가 있더라도 그 Store가 접근하는 메모리 주소를 
  계산하기 전까진 Load들을 Commit을 하지 않는 것으로 실행 취소가 가능하다.

1. #로 시작하는 지시자의 지시에 따라 소스코드를 변경하는 작업 수행 [본문으로]
2. 소스코드를 어셈블리 코드로 번역하는 작업수행 [본문으로]
3. 어셈블리 코드를 Binary Code 로 변경하는 작업 수행 [본문으로]
4. 프로그램 내에서 참조하는 함수, 라이브러리들을 연결시켜주는 작업을 수행. tip. 컴파일 중에 LNKXXX 에러가 뜨며, 함수를 찾을 수 없다는 에러를 본 적이 있을 것이다 [본문으로]
5. CPU 에게 작업을 시키기 위한 명령어 [본문으로]
6. Register(REG or R) : 연산유닛과 연결된 액세스속도가 가장 빠른 기억장치. 임시적으로 데이터 저장을 위한 아주 작은 메모리로 2진 데이터 저장. [본문으로]
7. Program Counter(PC) : 다음에 인출할명령어의 주소를 가지고 있는 레지스터, 각 명령어가 인출된 후에는 명령어 길이만큼 주소를 증가시킴으로써 주소를 포인팅함. 분기(jump) 명령어가 실행되는 경우에는 목적지주소로 갱신한다 [본문으로]
8. Instruction Register(IR) : 현재 실행중인 명령의 내용을 기억하고 있는 레지스터 [본문으로]
9. 각종 산술연산(덧셈, 뺄셈, 곱셈, 나눗셈)과 논리연산(AND, OR, NOT, XOR 등)들을 수행하는 회로들로 이루어진 회로. [본문으로]
10. Control Unit : 명령어를 해석하고, (프로그램을 컴파일 하면 실행파일이 생성되고 그 파일 안에 명령어들이 존재) 그것을 실행하기 위한 제어 신호들(control signals)을 순차적으로 발생하는 회로. [본문으로]
11. 명령어 및 데이터를 CPU 로 이동. 각 디바이스들이 서로 데이터를 주고 받기 위해 있는 매개체로 버스가 어떻게 데이터를 전송하는지, 그에 대한 프로토콜 혹은 통신 방식을 알고 있음. [본문으로]
12. 많은 저전력 CPU가 이러한 구조이다. 가령 예전의 Atom CPU가 그러하다. [본문으로]
13. 실행할 명령어들을 가져온다. 이후 단계들도 그렇지만, 한 번에 보통 4개 정도를 처리하는데, Superscalar라고 불리는 기술은 이렇게 한 사이클에 여러 명령어를 처리하는 것을 말한다. [본문으로]
14. 이후 처리를 돕기 위해 명령어의 종류를 구분한다. Intel의 x86 ISA같이 복잡한 명령어를 쓰는 CISC의 경우, 내부적으로 RISC 명령어들로 쪼개지는 과정이 여기서 수행된다. 옛날 프로그램을 짜기 어려웠던 이유는 바로 이 디코드 동작시 불러오는 CPU 명령함수들이 CPU마다 전부 다 다르다는 것 때문이었다. 현재는 몇 개 회사가 CPU 공급을 독점하면서 그나마 단순화되었다. (같은 회사는 추가 기능이 없다면 같은 명령함수를 쓰는 게 일반적) [본문으로]
15. 명령어가 가리키는 레지스터(CPU에서 값을 저장하는 x86 ISA의 eax나 ebx등의 이름있는 공간들)를, 내부에 숨어있는 물리적 레지스터로 매핑한다. 이러한 과정은 Out-of-order CPU에서 발생하는 False-dependency 문제를 해결하기 위해 필수적이다. [본문으로]
16. 명령어가 실행하기 위해 기다리는 대기열 (ROB, IQ, LSQ)에 명령어를 넣는다. [본문으로]
17. 대기열에 있는 명령어가 실행될 수 있으면 실행하기 위한 장치(가령 계산 명령어는 ALU, 메모리 명령어는 Cache)로 보낸다. 참고로 프로그램에서 시간상 뒤의 명령어가 앞의 명령어보다 먼저 Issue될 수 있다. 이것이 바로 Out-of-order CPU의 핵심 동작 중 하나다. [본문으로]
18. 실행한다 [본문으로]
19. 결과값을 레지스터에 써야 한다면 쓴다. 결과값을 기다리고 있던 명령어가 있다면 결과가 생겼다고 알려준다. [본문으로]
20. 명령어 수행을 완료하고, 명령어 실행을 위해 할당받은 자원을 모두 토해낸다. 명령어의 실행 결과를 사용자에게 노출시키며 (이거 전에는 노출이 안 된다), 이후로는 명령어의 실행을 취소할 수 없다. [본문으로]