파이프라인에서의 Commit Stage 의 역할
내부적으로는 비순차적으로 실행하는 것을 결과적으로 순차적 실행처럼 보이게 하려면 pipeline 의 마지막에 특정한 단계를 하나 추가해야 하는데 이를 Commit Stage 라고 합니다.
비순차 프로세서에서는 중간의 실행과정들이 순서가 뒤바뀔 수 있습니다. 그런데, 이런 뒤죽박죽인 순서대로 사용자에게 결과를 보여주면 안되겠죠. Commit 단계는 이렇게 뒤섞인 순서를 정리하여 최종적으로 사용자에게는 프로그램의 순서와 동일하게 보여주도록 하는 역할을 수행합니다.
중간이야 병렬적으로 수행했건 어쨌건 결과가 사용자에게 정확한 순서로 보이기만 하면 되므로, 비순차적 실행 결과들을 모아서 적절한 시점에 순차적으로 완료단계를 거치도록 하면 아무 문제가 없을 것입니다.
이를 마이크로 아키텍쳐에서는 프로세서가 구조적 상태(Architectural State)와 투기적 상태(Speculative State)라는 두가지 상태로 동작한다고 말합니다.
구조적 상태는 마치 프로세서가 명령어를 순차적으로 실행하는 것처럼 보이도록 Commit 시점에 변경되는 상태를 말합니다.
반면 투기적 상태는 그 반대겠죠.
분기예측이나 메모리 의존성 예측과 같은 각종 투기적 기법을 동원하여 파이프라인이 끊기지 않고 지속적인 실행을 할 수 있도록 하고 있습니다. 이럴 때 투기적 상태는 변하지만 사실 그 상태가 프로세서의 정확한 상태라고 보장할 수는 없습니다.
정확한 상태를 보장할 수 없기 때문에 투기적 상태는 당연히 잘못되었다고 확인되는 순간 원래의 정상적인 구조적 상태로 돌려야 합니다.
Commit 단계는 결국 이러한 구조적 상태에 대한 보장을 할 수 있도록 하는 다음 작업들을 담당하게 됩니다.
- Reorder Buffer 에서 실행이 끝난 것을 순차적으로 Register File 이나 메모리(캐쉬)에 반영한다. 참고로 이렇게 반영(Commit)되기 이전에는 Reorder Buffer 의 operand 들이 issue 단계에서 이용될 수 있다.
- 실행 도중 Exception 이 발생했을 경우 수행중인 모든 instruction 을 취소하고 exception handler 를 위한 명령어에 대한 fetch 부터 다시 시작한다.
- 분기 예측 실패(Branch Misprediction) 시는 다음의 두가지 종류의 작업이 수행된다.
Front-End 복구 : wrong path 로 Fetch 된 모든 명령어들을 Buffer 에서 비우고, 분기예측기(Branch Predictor)의 History 를 복구하고, PC 를 되돌려 correct path 를 위한 명령어부터 다시 Fetch 하도록 한다.
Back-End 복구 : Reorder Buffer, Load-Store Buffer, Reservation Station 에 있는 모든 명령어들을 비우고, Renaming Table 또한 correct path 를 위해서 복구를 수행하고, 사용하던 물리 register 들도 반환된다.
References:
- https://class.stanford.edu/c4x/Engineering/CS316/asset/Processor_Microarchitecture.pdf
- 김민장의 “프로그래머가 몰랐던 멀티코어 CPU 이야기”
