ISA & Control Unit Logic

1. Overview

명령어 집합 구조와 제어 논리(ISA & Control Unit Logic, ICL)는 하드웨어(트랜지스터 덩어리)와 소프트웨어(운영체제와 컴파일러)가 서로 알아듣고 소통하기 위해 체결한 극도의 억압적이고 정교한 '최후의 기계어 통신 규약'입니다.

학습자는 C/C++ 소스 코드가 컴파일러에 의해 잘게 찢어져, 레지스터와 메모리를 움직이는 명령어 단위 집합인 ISA (Instruction Set Architecture) 규격으로 번역되는 어셈블리어의 문법을 뜯어봅니다. 나아가 이 32비트 기계어 스트링(0101...)을 씹어 먹고, 데이터 경로 상의 수십 개 MUX와 ALU 스위치를 열고 닫는 오케스트라 지휘자, **제어 유닛(Control Unit)**의 하드코딩된 디코딩 물리를 해부하여 CPU 설계의 브레인을 이식하는 아키텍트 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• 명령어 집합 규격 (ISA Physics): RISC(Reduced ISA) vs CISC(Complex ISA) 설계 철학, MIPS/RISC-V/x86 아키텍처 비교.
• 기계어 인코딩 포맷 (Instruction Formats): 연산 코드(Opcode), R-포맷(Register), I-포맷(Immediate), J-포맷(Jump), 피연산자 할당 기하학.
• 주소 지정 방식 (Addressing Modes): 레지스터 주소 지정, 즉치(Immediate), 베이스-오프셋(Base-Offset), PC-상대(PC-Relative) 점프.
• 제어 유닛 로직 (Control Unit Design): 하드와이어 제어(Hardwired Control, 논리 게이트), 마이크로프로그래밍(Microprogrammed Control).

Out-of-Scope

• 어셈블리어 애플리케이션 작성: NASM/MASM으로 수백 줄짜리 테트리스 게임 어셈블리 코드 짜기 $\rightarrow$ 애플리케이션 프로그래밍 영역.
• 컴파일러의 추상 구문 트리(AST) 렌더링: C 코드가 어떻게 어셈블리어로 최적화(O3)되어 변역되는가 $\rightarrow$ 05-03. Compilers & Code Generation 영역.

Boundaries

• ICL vs. Data Path Design (02-01-03): 데이터 경로 설계(02-01-03)가 "ALU와 메모리를 연결해 놓은 근육과 핏줄(파이프관)"이라면, ICL은 "날아오는 32비트 명령어를 쪼개어, 각 파이프관의 스위치(MUX 밸브)에 전기 신호(0/1)를 쏘아주는 CPU의 대뇌(Brain)"입니다. 두 개가 결합해야 CPU가 비로소 살아 숨 쉽니다.

3. Counterexample

• ISA 포맷 난립의 저주 (Instruction Decoding Hell): 인텔 x86(CISC)처럼 명령어 길이가 1바이트부터 15바이트까지 미친 듯이 늘어났다 줄어들었다 하는 포맷을 채택할 때 벌어지는 참사. 명령어를 어디서 끊어 읽어야 할지(Fetch) 디코더가 매 사이클마다 헤매느라(Complex Decoding) 컨트롤 유닛이 수만 개의 트랜지스터로 떡칠되어 발열이 터지고 파이프라인 설계가 붕괴해버리는 극한의 물리적 고통입니다.
• 오프셋 비트 부족의 점프 붕괴 (Jump Truncation Fallacy): 브랜치(Branch) 명령어를 짤 때, J-포맷의 오프셋 비트(Offset Bits) 한계를 계산하지 않고 수백만 줄짜리 코드를 넘어 뛰려(Jump)고 시도하는 어셈블리 뉴비의 실수. 허용된 비트 수(예: 16비트 = $\pm 32KB$)를 넘어선 주소로 점프 명령을 내리면, 상위 비트가 짤려(Truncation) 전혀 엉뚱한 운영체제 커널 코드로 점프해버려 세그먼테이션 폴트(Segmentation Fault)를 맞고 사살당합니다.

4. Prerequisites

• 디지털 논리 및 레지스터 파일 (Basic): 32비트 기계어가 디코딩되어 여러 뭉치의 전기 신호로 갈라져 MUX 핀에 꽂힌다는 사실을 이해하려면 기본 하드웨어 논리가 필수입니다. (02-01-01 DLB, 02-01-03 ADP)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: RISC와 CISC의 아키텍처 철학 대결 (RISC vs CISC)

• Why to Learn: 애플 M1칩(ARM/RISC)이 왜 인텔 칩(x86/CISC)을 배터리와 발열 측면에서 압도적으로 찢어버리며 패러다임 시프트를 일으켰는지 그 뿌리를 장악하기 위함입니다.
• What to Learn:
  • Concepts: RISC(Reduced Instruction Set Computer), CISC(Complex Instruction Set Computer).
  • Skills: 명령어의 길이 가변/고정(Fixed/Variable Length), 메모리 접근 방식(Load-Store Architecture).
  • Tools: x86 vs ARM 어셈블리 비교.
  • Trade-offs: "메모리에서 읽어와서 레지스터랑 더한 다음 다시 메모리에 꽂아라"를 단 한 줄의 명령어로 처리하는 CISC의 컴파일러 편의성(코드 길이 단축) vs 이 복잡성을 몽땅 버리고 "명령어는 무조건 레지스터끼리만 연산한다(Load/Store 분리)"는 룰을 강제하여 하드웨어 파이프라인을 미친 속도로 뽑아내는 RISC의 속도전.
• How to Learn:
  • 1단계: 메모리는 너무 느려서 ALU와 직접 대화할 자격이 없으며, 오직 Load와 Store 명령어만 메모리를 건드리고 나머지 모든 덧셈/뺄셈은 0.1ns짜리 레지스터 파일 내부에서만 놀도록 격리시킨 RISC의 강박증적 샌드박스 물리를 해부합니다.
  • 2단계: 과거 1980년대에는 램(RAM) 용량이 너무 비싸 코드를 압축(CISC)해야만 했지만, 지금은 램이 넘쳐나므로 하드웨어를 극도로 단순화해 클럭을 5GHz로 땡기는(RISC) 실리콘 경제학의 변화를 뜯어봅니다.
• Implement: 파이썬으로 가상의 CPU 실행 루프를 만들어, $A = B + C$ (메모리 변수) 연산을 할 때 1개의 CISC 명령어(ADD [A], [B], [C])로 처리하는 사이클 수와, 4개의 RISC 명령어(Load, Load, Add, Store)로 쪼개어 처리할 때의 파이프라인 중첩 효과 사이클 수를 비교 프린트하는 시뮬레이터.

Recommended

Core Topic 02: 32비트 기계어 인코딩 팩토리 (Instruction Formats)

• Why to Learn: 허공에 떠도는 어셈블리어 텍스트(add x1, x2, x3)가 어떻게 0과 1로 빈틈없이 패킹(Packing)되어 32개의 전깃줄을 타고 CPU 코어로 돌진하는지 포맷을 해부하기 위해서입니다.
• What to Learn:
  • Concepts: R-Type(레지스터 3개), I-Type(레지스터 2개 + 상수), J-Type(점프 전용 상수).
  • Skills: Opcode, rs1, rs2, rd, 펑션 코드(Funct3, Funct7).
  • Tools: RISC-V 인코딩 테이블 / 비트마스크(Bitmask).
  • Trade-offs: 32비트 안에서 상수(Immediate)를 32비트 통째로 넣고 싶지만 오퍼코드(Opcode)와 레지스터 주소가 자리를 파먹어 상수의 크기가 12비트(최대 $\pm 2048$)로 쪼그라드는 비트 영토 분쟁의 딜레마.
• How to Learn:
  • 1단계: R-포맷 32비트를 [Opcode 7비트][rd 5비트][f3 3비트][rs1 5비트][rs2 5비트][f7 7비트] 로 갈기갈기 찢었을 때, 5비트가 레지스터를 나타내는 이유가 레지스터 개수가 딱 32개($2^5$)로 하드웨어 제한이 걸려있기 때문임을 역추적해 해부합니다.
  • 2단계: Opcode 7비트만 보면 이것이 "레지스터 연산(R)인지 메모리 로드(I)인지 점프(J)인지" 큰 줄기를 알 수 있고, 하위 펑션 코드(Funct)가 덧셈/뺄셈의 잔가지를 결정하는 계층적(Hierarchical) 기계어 트리를 뜯어봅니다.
• Implement: 어셈블리 텍스트 스트링 addi x5, x0, 10 (I-Type)을 파이썬 파서(Parser)로 입력받아, Opcode(0010011), rd(00101), rs1(00000), imm(000000001010)으로 비트 분해한 뒤, 이를 합쳐 0x00A00293이라는 최종 32비트 헥스(Hex) 바이너리 값으로 뽑아내는 꼬마 어셈블러 모듈 작성.

Practical

Core Topic 03: 데이터 좌표와 주소 지정의 기하학 (Addressing Modes)

• Why to Learn: 프로그램이 분기(Branch)를 탈 때나 배열(Array) 데이터를 긁어올 때, 메모리 지도의 어떤 좌표(Pointer)를 때려야 하는지 길 찾기 라우팅을 박아넣기 위함입니다.
• What to Learn:
  • Concepts: 유효 주소(Effective Address).
  • Skills: 레지스터 지정(Register), 즉치 지정(Immediate), 베이스-오프셋 지정(Base-Offset), PC-상대 지정(PC-Relative).
  • Tools: 포인터 덧셈 물리학.
  • Trade-offs: 메모리 주소 32비트를 몽땅 명령어 안에 욱여넣으려는 절대 주소 지정(Absolute)의 무식한 비트 낭비 vs "현재 위치(PC)에서 +100칸 앞"으로 지정하여 코드가 메모리 어디로 쫓겨나도 완벽히 작동하는 위치 독립 코드(PC-Relative, PIC)의 압도적 유연함.
• How to Learn:
  • 1단계: C 언어의 배열 접근 A[5]가 기계어 레벨에서는 "A 배열의 시작 번지(Base Register) + 5칸만큼 떨어진 오프셋(Immediate)"을 덧셈기(ALU)에 밀어 넣어 물리적인 메모리 번지를 창조해 내는 Base-Offset 로직임을 해부합니다.
  • 2단계: if 블록을 건너뛰는 조건 점프(Branch)를 할 때, 점프 거리가 명령어 자체에 박혀있어 런타임에 $PC = PC + (Offset \times 4)$ 라는 덧셈 연산으로 폭발하는 PC-상대 지정 궤적을 뜯어봅니다.
• Implement: 32비트 메모리 주소 배열과 현재 PC 위치가 주어졌을 때, 명령어의 Addressing Mode(Immediate, Base-Register, PC-Relative) 플래그에 따라 유효 주소(Effective Address) 정수값을 계산해 정확히 리턴하는 주소 변환기 엔진.

Advanced

Core Topic 04: 제어 유닛의 하드코딩과 브레인 이식 (Control Unit Logic)

• Why to Learn: 명령어 인코딩을 해석하여, 데이터 패스 챕터에서 만들었던 10여 개의 MUX와 ALU의 방향타(스위치 핀)에 0과 1의 전기 펄스를 쏘아 보내는 진짜 대뇌 피질을 창조해 내기 위함입니다.
• What to Learn:
  • Concepts: 제어 신호(Control Signals: RegWrite, ALUSrc, MemRead, MemtoReg, Branch).
  • Skills: 하드와이어 제어(Hardwired Control), 진리표(Truth Table) 기반 게이트 매핑.
  • Tools: 마이크로코드(Microcode) 개념 기초.
  • Trade-offs: 제어 신호를 순수한 AND/OR 게이트 로직 보드로 구워버려(Hardwired) 빛의 속도로 쏘아내는 RISC의 속도전(수정 불가) vs 제어 신호 패턴을 ROM 메모리 테이블에 박아놓고 하나씩 읽어 쏘는(Microcode) CISC의 유연함(하지만 느림).
• How to Learn:
  • 1단계: R-Type 덧셈 명령어가 떴을 때, 제어 유닛이 0.1나노초 만에 RegWrite=1 (저장해), ALUSrc=0 (레지스터 읽어), MemtoReg=0 (메모리는 무시해) 등 10개 핀의 진리표를 와이퍼 블레이드처럼 한 방에 스위칭하는 하드코딩 역학을 뜯어봅니다.
  • 2단계: 오퍼코드(Opcode) 7비트가 컨트롤 유닛의 거대한 AND-OR 게이트 숲으로 빨려 들어가, 조건문(if Opcode == 0110011 then...) 없이 순수 전기의 물리적 흐름만으로 각 제어 신호 라인을 활성화(1)시키는 하드웨어 디코딩의 카타르시스를 해부합니다.
• Implement: 7비트 스트링(Opcode)을 입력하면, 하드코딩된 파이썬 딕셔너리 로직 게이트 매핑을 통해 8개의 제어 신호 핀 상태(예: {'RegWrite': 1, 'MemRead': 0, 'Branch': 0 ...})를 활성화하여 딕셔너리로 뿜어내는 가상 Control Unit 데몬 루틴 작성.

7. Terminology

8. References

Primary

• [P1] CS2023 - AR/Instruction Set Architecture — Specification standards.
• [P2] SWEBOK v4.0 - Computing Foundations / ISA — Industry definitions.

Secondary

• [Computer Systems: A Programmer's Perspective] Bryant & O'Hallaron — ISA from a software viewpoint.
• [The Art of Assembly Language] Randall Hyde — Deep dive into ISA mechanics.

Industry

• [ARMv8-A Architecture Reference Manual] — Real-world RISC ISA standard.
• [RISC-V Reader: An Open Architecture Atlas] — Modern open ISA design.

9. Final Checklist

Primary

• 특정 ISA의 명령어 포맷 중 'Immediate' 필드 크기가 프로그래밍 시 수치 상수에 미치는 물리적 제약을 입증할 수 있는 가? (P1)
• 제어 유닛의 '디코더' 회로가 기계어의 OPCode 비트를 물리적으로 어떻게 분리하여 장치 가동 신호로 변환하는지 서술 가능한가? (P1)

Secondary

• CISC 아키텍처의 복잡한 명령어가 호환성을 유지하면서도 RISC 스타일의 빠른 코어에서 실행될 수 있는 마이크로코드 구조를 설명 가능한가?
• 조건부 분기(Conditional Branch) 명령 시 제어 유닛이 ALU의 상태 플래그를 읽어 '결정'을 내리는 시리얼 논리 경로를 입증할 수 있는 가?

Industry

• 새로운 임베디드 시스템 설계 시, 전력 효율과 성능 목적에 따라 RISC 기반의 사용자 정의 ISA를 제안하고 그 타당성을 수학적으로 소통할 수 있는 가? (SFIA)
• 역공학(Reverse Engineering) 시, 바이너리 덤프에서 Opcode 오프셋을 분석하여 해당 코드가 안전한 연산 범위를 지키고 있는지 물리적으로 검증할 수 있는 가?