노는 게 제일 좋아

우리는 우리가 설계한 대로 굴러가길 바라지만 항상 세상은 뭔가 예외를 만든다. 여기에도 예외를 만든다. 알아보자 차에 기름이 부족하면 주유소에 멈추어서 기름을 넣고 간다. 그렇다면 우리 파이프라인에 문제가 생기면 그냥 무시하고 가나?? 멈춰서 문제 해결을 하고 가야한다. 도대체 실행중인 프로세서를 어떻게 멈추게 하고 문제를 해결할 것인가? 설계 다음으로 중요해졌다. 바로 예상치 못한 event 라는 것이 발생한다. 다시 말해서 Exception, Interrupt를 발생시킨다. Exception은 CPU 내부에서 발생하고 undefined 된 코드나 overflow 등등이 원인이다. Interrupt는 외부 I/O에 의해서 발생한다. (외부 장치에 의함, Hardware) **Software에서도 Int..

이번에는 Control Hazard이다. Branch할 때 많이 일어난다고 했다. 즉, Branch가 된다면 실제로 우리가 IF했던 것들이 쓸모가 없어질 수 있다. 또한 해당 결과는 MEM stage 에서 나오는데 MEM stage 동안 실행된 instruction을 다 Flush 시켜야 한다는 말이다. **Flush란 우리가 물내리는 거랑 같다. 그렇게 세 개의 싸이클이 날라가면 또한 그것도 엄청난 성능 손해다. 그래서 우리는 Load and Use에서도 봤다시피 Mem stage가 끝난 뒤 포워딩하는 것을 미리 ID에서 미리 detect 한 것과 같이 ID 단계에 장치를 추가한다. Target address adder Register comparator를 추가시킨다. ?? 어떻게 그렇게 하느냐? ID..

데이터 해저드에 대해서 조금 더 자세히 알아보자 말했다시피 데이터 해저드는 데이터 의존성 때문에 발생한다. sub의 결과가 뒤의 instruction에 사용된다. 다시 말해서 forwarding 을 하지 않으면 데이터 해저드가 발생한다. 사실 데이터 해저드가 발생해서 포워딩이 되는 것이 맞다. 근데 우리야 명령어 목록들을 보면 해저드가 발생할 것이고 forwarding을 언제 하면 되겠다는 걸 알 수 있는데 컴퓨터는 어떻게 detect를 할 수 있을까??? 다시 말하면 언제 해저드가 일어난다는 것일까?? 일반적으로 Read After Write 의 경우 쓰기 연산 후의 읽기인데 Write가 끝난 뒤에 Read를 해야한다는 말이다. 그렇지 않으면 Data Hazard가 발생한다. 데이터 해저드는 저 때 발..