⚠️ 예외 처리

프로세서의 다양한 동작은 예외적인 흐름을 발생시킬 수 있으며,
예외들은 내부적으로 발생하거나 외부적으로 발생할 수 있다.

내부적인 예외 원인

1. halt 인스트럭션에 의한 예외
2. 인스트럭션과 함수코드의 잘못된 조합
3. 인스트럭션 처리 중 유효하지 않은 주소에 접근

---

파이프라인을 사용한 시스템에서 예외처리는 여러가지 미묘한 부분들과 관계가 있는 경우가 있는데, 그 부분에 대해서 살펴보려고 한다.

🤔 예외 처리의 세 가지 미묘한 문제

📦 다중 예외 발생

• 예외가 동시에 다수의 인스트럭션에서 발생할 수 있음.
• 규칙: 파이프라인에서 가장 뒤(진행이 앞선) 단계의 예외가 우선적으로 처리된다.
• 예:
  • Fetch 단계: halt 명령 → halt 예외
  • Memory 단계: 주소 범위 초과 예외
  • 보고 대상: Memory 단계의 예외만 운영체제에 보고

🔄 분기 예측과 잘못된 예외 발생

• 파이프라인이 분기를 실행할 것이라고 예측하면,
  해당 분기 타깃 주소의 명령을 Fetch한다.
• 규칙: 파이프라인 제어로직은 이 인스트럭션을 취소한다.

🪜 다단계 상태 갱신 문제

• 파이프라인은 시스템 상태를 여러 단계에서 갱신한다.
• 문제: 예외 발생 명령어 이후 명령이, 예외 확정 전 일부 상태를 변경할 수 있다.

예시 코드:

1  irmovq $1, %rax           # RAX ← 1
2  xorq %rsp, %rsp           # RSP ← 0, CC ← 100
3  pushq %rax                # 스택 포인터 감소 → 0xfffffffffffffff8 → 주소 예외(사용자가 접근할 수 없는 주소로 가정)
4  addq %rax, %rax           # (실행되면 안 됨) CC ← 000

• pushq → 메모리 단계에서 주소 예외 발생.
• 같은 사이클 addq → 실행 단계에서 CC 변경 시도.
• 문제: 예외 이후의 명령이 프로그래머 가시 상태를 변경함.

---

위에서 말한 예외들에 대해서 어떠한 방법으로 우리가 언급한 미묘한 점들을 처리하는지 생각해보자

💊 예외 처리 해결 방법

☑️ 상태코드 필드

상태코드(stat) 필드를 사용하자

• 각 파이프라인 레지스터에 상태 코드(stat) 필드 추가
• 예외 발생 시, 해당 명령어의 stat에 예외 종류 기록
• 상태 정보는 Write-back 단계까지 전파
• Write-back 단계에서 예외 감지 → 프로그램 실행 중단, 상태 코드 기록

☑️ 상태 변경 억제 규칙

예외 발생 후, 뒤의 명령어는 프로그래머 가시 상태를 변경해서는 안된다.

즉, 예외가 난 시점 이후의 명령들은 CPU 안에서는 파이프라인에 들어와 있더라도, 프로그램이 볼 수 있는 상태(레지스터 값, 메모리 내용 등)를 절대로 바꾸면 안 된다.

📚 동작 방식 정리

1. 예외 상태는 발생한 단계에서 stat에 저장.
2. 파이프라인 흐름을 따라 Write-back까지 전달.
3. Write-back 단계에서 감지되면 실행 중단 및 상태 코드 보고
4. 예외 이후의 명령은 상태 변경 불가
5. 분기 오예측 취소 시, 예외 상태도 같이 폐기
6. 동시에 여러 예외가 발생하면, 가장 진행이 앞선 명령 예외만 보고.

---

🛠️ PIPE 단계의 구현

이 부분에서는 Y86-64 PIPE 프로세서가 실제로 어떻게 명령어를 처리하는지,
각 단계별(Fetch → Decode → Execute → Memory → Write back) 역할과 데이터 흐름, 그리고 우회망(Forwarding), 스톨/버블 제어, 예외 처리, 성능 분석 등을 하드웨어 제어 관점에서 살펴보려고 한다.

☑️ Fetch 단계(F)

• 할 일: 메모리에서 명령 바이트 읽기 → 분해(Split/Align) → 필요시 rA/rB, valC, valP 산출 → 예측 PC 계산.
• 필요 바이트 판단: Need_regids, Need_valC (명령 종류별)

☑️ Decode 단계(D)

• 할 일: 소스/목적 레지스터 결정(d_srcA, d_srcB, d_dstE, d_dstM) → 레지스터 파일/우회망에서 최신 값 선택 → d_valA, d_valB 생성.

🧩 Sel+Fwd A 블록과 Forwarding 우선순위

💡 회로가 하는 일

그림 속 Sel+Fwd A 블록은 두 가지 일을 동시에 한다.
1. valP + valA 병합

• valP : 다음 명령어 주소(PC + 명령어 길이)
• valA : 명령어 실행에 필요한 레지스터 값
• CALL, JXX 같은 특정 명령만 valP가 필요하니까, 나머지 경우는 valA로 대체해서 전달
  → 파이프라인 레지스터에 저장해야 하는 정보(상태)를 줄임

2. Forwarding(우회, 데이터 전달)
   • 아직 레지스터 파일에 기록되지 않은 최신 값을, 뒤의 명령이 바로 가져다 쓰게 함
   • 이유 : 파이프라인에선 명령들이 겹쳐 실행되기 때문에, 뒤의 명령이 갱신되기 전 값을 읽는 걸 방지해야 함

💬 우선순위가 필요한 이유

Forwarding 경로는 여러 군데에서 값이 올 수 있음.

• EX 단계 (ALU 계산 결과)
• MEM 단계 (메모리 읽기 결과)
• WB 단계 (레지스터 쓰기 직전 결과)

같은 레지스터를 여러 명령어가 갱신하려고 할 때,
프로그램 실행 순서상 가장 나중에 실행될 명령어의 값을 선택해야 한다.
파이프라인에서는 이 값이 가장 앞쪽(earliest) 단계에 위치해 있다.

이유: 프로그램 순서에서 더 나중에 위치한 명령어가 결국 최종적으로 레지스터를 덮어쓰게 되므로, 그 값을 미리 전달해야 한다.

예) E 단계에 있다면, 같은 사이클에서 M 단계나 W 단계에 있는 값보다 “최종값”이므로 우선순위가 더 높다.

🔢 실제 우선순위

우선순위	조건	사용 값	출처(Stage)	이유
1	E_dstE == d_src	e_valE	Execute 단계 ALU 결과	가장 최신 값이 Execute 단계에서 바로 나왔기 때문에, 메모리·레지스터에 기록되기 전이라도 이 값을 쓰면 지연 없이 최신 결과 사용 가능
2	M_dstM == d_src	m_valM	Memory 단계에서 읽은 메모리 값	Memory 단계에서 메모리 읽기(load)로 얻은 값이므로, 이 시점에서만 얻을 수 있는 최신 데이터
3	M_dstE == d_src	M_valE	Memory 단계에서 ALU 결과	Execute에서 나온 값이지만 지금 Memory 단계에 있으므로, 1번보다 한 사이클 늦음
4	W_dstM == d_src	W_valM	Write-back 단계에서 메모리 값	메모리에서 읽어서 이제 레지스터에 기록 직전인 값. 이전 단계보다 한 사이클 더 지난 값
5	W_dstE == d_src	W_valE	Write-back 단계에서 ALU 결과	ALU 계산 결과를 레지스터에 기록 직전. 가장 오래된 값이므로 우선순위 가장 낮음
6	그 외	d_rvalA	Register File	위 모든 경우에 해당 안 될 때만 레지스터 파일 값 사용

예시) E_dstE == d_src : Execute 단계에 있는 명령어의 목적지 레지스터(E_dstE)가, Decode 단계에서 읽으려는 소스 레지스터와 같으니까 Execute결과인 e_valE을 갖다 사용해도 된다는 뜻

---

☑️ Execute 단계(E)

• 할 일:
  • aluA/aluB 선택 → ALU 연산(alufun) → e_valE 생성
  • 분기 판단(e_Cnd)
  • 필요 시 CC 갱신(set_cc) : m_stat, W_stat 입력을 사용해 메모리 단계나 Write-back 단계에서 예외가 발생한 경우 CC를 업데이트하지 않도록 함
• 분기 판단: 조건 코드(CC) 기반(예: ZF, SF, OF), cmovXX/jXX에 사용

☑️ Memory 단계(M)

• 할 일: 메모리 읽기/쓰기, 주소 예외 감지
• Mem.data 삭제 : Sel+Fwd A 블록에 의해서 처리되므로 필요 없어짐

☑️ Write back 단계(W)

• 할 일: 레지스터 파일에 결과 쓰기
  • W_dstE := W_valE, W_dstM := W_valM
• 예외 시: 쓰기 금지(정밀 예외 보장).

---

🚦 파이프라인 제어 로직

이제 마지막으로 파이프라인 제어 로직만 만들면 PIPE 설계가 끝나는데
이 로직은 데이터 포워딩이나 분기 예측으로는 해결할 수 없는 네 가지 제어 상황을 처리하기 위한 것이다.

💭 제어 상황

1. Load/use 해저드

   • 메모리에서 값을 읽는 명령과, 그 값을 바로 사용하는 다음 명령 사이에 1 사이클 스톨

2. ret 처리

   • ret 명령이 Write-back 단계에 도달할 때까지 파이프라인 정지

3. 분기 예측 실패

   • 잘못된 분기가 확인되면 이미 파이프라인에 들어간 잘못된 명령들을 취소하고, 올바른 명령부터 다시 가져온다.

4. 예외 발생

   • 예외를 발생시킨 명령 이후의 명령이 프로그램 상태를 변경하지 못하게 하고,
     해당 명령이 Write-back 단계에 도달하면 실행을 중지해야 한다.

---

특수 제어 상황 처리 방법

☑️ Load/use 해저드

• 해당: mrmovq, popq (메모리 읽기) 명령
• 조건:
  1. 해당 명령이 Execute 단계에 있음
  2. 다음 명령이 같은 레지스터 값을 필요로 함
• 처리:
  • Decode 단계의 두 번째 명령 대기 (파이프라인 레지스터 D 고정)
  • 다음 사이클에 Execute 단계에 버블 삽입
  • Fetch 단계(F)도 고정해 동일 명령을 다시 가져오게 함
  • 이후 포워딩 로직으로 해저드 해결

☑️ ret 처리

• 3 사이클 동안 정지
• ret이 Memory 단계에서 반환 주소를 읽을 때까지 Fetch 단계가 정상적으로 진행되지 않음
• Decode 단계에 버블 삽입 → 잘못된 명령이 실행되지 않도록 함
• 반환 주소 확보 후 올바른 명령부터 Fetch 재개

☑️ 분기 예측 실패

• 분기 결과는 Execute 단계에서 확인됨
• 잘못된 명령을 Decode/Execute 단계에서 버블로 교체
• 올바른 주소로 Fetch 재시작

---

예외 처리

• 각 파이프라인 레지스터에서 명령의 상태 코드를 추적
• 예외 시:
  1. Memory 또는 Write-back 단계에서 예외가 발생하면 CC 갱신 비활성화 (set_cc = 0)
  2. Memory 단계에 버블 삽입 → 메모리 쓰기 방지
  3. Write-back 단계 정지 → 파이프라인 전체 중단

---