- 기술을 논의할 때 그 진화 과정을 이해하지 못하고 현재에만 집중한다면 절대 그 기술을 이해할 수 없을 것임.
- 프로그래머의 눈에 보이는 CPU
- 어떤 복잡한 대규모 응용 프로그램이든 간에 결국 컴파일러로 하나하나 간단한 기계 명령어로 변환함.
- 본질적으로 CPU 입장에서 프로그램에 따른 차이가 없음.
- 단지 명령어가 많은지 적은지의 차이만 있을 뿐임.
- CPU는 단순하게 실행파일에 적힌 명령어가 메모리에 적재되면 그걸 읽어 실행하기만 함.
- CPU의 능력 범위: 명령어 집합
- CPU 유형에 따라 고유한 능력 범위를 가지고 있음.
- 이를 명령어 집합(instruction set architecture) 라고 함.
- 명령어 집합에는 여러 가지 명령어가 포함됨.
- 명령어 집합은 프로그래머가 프로그래밍에 사용함.
- 서로 다른 형태의 CPU는 다른 유형의 명령어 집합을 가지고 있음.
- 명령어 집합 유형은 프로그래머가 코드를 작성할 때 뿐 만 아니라 CPU 하드웨어 설계에도 영향을 미침.
- 어떤 유형의 명령어 집합을 사용해야 하는지, CPU가 어떻게 설계 되어야 하는지에 대한 논쟁은 지금까지 계속되고 있음.
- 첫 번째 명령어 집합 유형이자 처음으로 탄생했던 명령어 집합인 복잡 명령어 집합 컴퓨터(Complex Instructrion Set Computer, CISC)가 있음.
- 현재의 데스크톱 PC, 서버에 공통으로 사용하는 x86 구조(architecture) 는 복잡 명령어 집합에 기초하고 있음.
- x86 프로세서를 생산하는 업체는 인텔(intel)과 AMD 임.
- 추상화: 적을수록 좋다.
- 예전에는 컴파일러가 성숙하지 못했기에, 많은 프로그램이 어셈블리어로 작성되었음.
- 현대에는 컴파일러가 충분히 강력하고 지능적임.
- 따라서 운영체제와 드라이버를 작성하는 사람을 제외한 현대 프로그래머는 어셈블리어의 존재를 거의 인지하지 못함 → 생산성 향상되고 있음을 의미함.
- 그 당시의 컴퓨터 과학자는 직접 어셈블리어로 명령어 집합을 더욱더 풍부하기 만들어 명령어 자체 기능을 더 강력하게 만들었음.
- 함수 호출, 순환 제어, 복잡한 주소 지정 패턴, 데이터 구조, 배열 접근 → 이러한 내용을 고급 언어의 개념과 대응하는 기계 명령어가 있어야 한다고 생각함.
- 이를 의미상 간격(semantic gap) 을 이어 준다고 함.
- 코드도 저장 공간을 차지한다
- 현재의 컴퓨터는 기본적으로 폰 노이만 구조(Von Neumann architecture)를 따름.
- 저장에 있어 프로그램과 프로그램이 사용하는 데이터에 어떠한 차이도 없어야 함.
- 모두 컴퓨터의 저장 장치 안에 저장될 수 있어야 함.
- 폰노이만 구조는 다음을 모두 포함함.
- 입력 장치 / 출력 장치
- 중앙 처리 장치 (제어장치 +산술/논리 장치)
- 메모리 장치
- 즉, 기계 명령어와 데이터를 모두 포함함.
- 프로그래머가 작성한 코드는 디스크 저장공간을 차지하며 실행시에 메모리에 적재되므로 메모리 저장 공간을 차지함.
- 1970년대 메모리는 수십 KB 에 불과했음.
- 매우 작은 저장 공간이라, 여기에 더 많은 프로그램을 적재하려면 기계 명령어를 반드시 매우 세밀하게 설계해서 프로그램이 차지하는 저장 공간을 줄여야 함. → 이에 따른 요구 사항을 만족해야 함.
- 하나의 기계 명령어로 더 많은 작업을 완료할 수 있도록 프로그래머가 더 효율적으로 코드를 작성할 수 있게 해줌.
- 기계 명령어 길이가 가변적이므로 프로그램 자체가 차지하는 저장 공간을 줄임
- 기계 명령어는 밀도를 높여 공간을 절약하려고 고도로 인코딩 됨.
- 필연적인 복잡 명령어 집합의 탄생
- 명령어를 사용한 편리한 프로그램을 작성하고 코드의 저장 공간을 절약하기 위해 복잡 명령어 집합을 설계해야하는 필요성이 대두됨.
- 복잡 명령어 집합의 출현은 당시 산업계 요구 사항을 충분히 만족시킴.
- 그러나 이는 문제가 있었음.
- 당시 CPU 명령어 집합은 모두 직접 연결(hardwired) 방식임.
- 명령어 인출(IF), 명령어 해독(ID), 실행(EX) 등 각 단계가 특정 조합 회로로 직접 제어됨
- 명령어 실행에는 매우 효율적이지만 명령어 집합 변경에 대응하기 어려웠음.
- 하드웨어의 설계를 변경하는 건 매우 번거롭지만 소프트웨어로 쉽게 변경할 수 있었음.
- 대부분의 명령어에 포함된 연산을 더 간단한 명령어로 구성된 작은 프로그램을 정의하여 CPU에 저장했음.
- 이렇게하면 모든 기계 명령어에 대응하는 전용 하드웨어 설계할 필요가 없음.
- 소프트웨어가 하드웨어를 대체하게 됨 → 더 간단한 명령어가 마이크로 코드(microcode) 임.
- 더 많은 명령어를 추가할 때 마이크로코드 수정에 집중하면 됨.
→ CPU 설계 복잡도를 낮출 수 있음.
- 마이크로코드 설계의 문제점
- 버그는 피할 수 없다..
- 마이크로코드의 버그를 수정하는 것은 일반 프로그램의 버그를 수정하는 것보다 훨씬 더 어려움
- 이를 해결하기 매우 어려우며, 더 나은 설계를 고민함.
댓글