컴퓨터구조(4) - 프로세서(3)

‘컴퓨터 구조 및 설계’를 공부하여 정리한 내용입니다.

9. 예외 (Exception)

제어를 다룬다는 것

• 제어는 프로세서 설계에 있어서 가장 다루기 어려운 영역

  • 올바르게 동작하는가?
  • 충분히 빠르게 동작하는가?

• 그 중에서도 예외와 인터럽트를 올바로 구현해두었는가?

  • 이는 분기와 점프와 다르게, 명령어 실행의 정상적인 흐름을 바꾸는 사건이다.
  • 이들은 처음에 프로세서 내부로부터의 예상치 못했던 사건을 처리하기 위해서 만들어졌다.
  • 앞에서 봤던 오버플로가 하나의 예시가 되겠다.
  • OS에서 프로세서를 계속해서 바꾸는 경우는 인터럽트의 예시가 될 수 있다.
  • 둘은 엄밀히 제어 과정에서 벌어지는가, 외부의 영향으로 일어나는가에 따른 차이가 있기는하다.
  • 하지만, 처리하는 방식이 같기 때문에, 굳이 나눌 필요는 없다.

MIPS 구조의 예외 처리

• 기억해야 하는 것들을 몇가지 정리해두겠다.
• 운영체제가 예외를 처리하려면 예외를 일으킨 명령어 뿐 아니라, 예외의 원인을 파악해야한다.

• 예외의 원인을 알아내기 위해서는 Cause 레지스터라고 불리는 상태 레지스터를 사용한다.

  • 여기에는 예외의 원인을 나타내는 필드가 있다.
  • 예시로는 오버플로가 일어났는가 하는 것을 기록하는 것이다.
  • ARM에서는 Overflow가 일어나려고 하면 값을 최댓값(혹은 최솟값)으로 고정시키고, Sturate되었다는 것을 기록하는 필드도 가지고 있다. (MIPS도 아마 가지고 있을 것 같다. 알아보지는 않았다.)
• 또다른 예외의 원인을 알아내는 방법은 벡터 인터럽트(vectored interrupt)를 사용하는 것이다.
  • 예외의 원인에 따라 제어를 처리하는 주소를 각각 두는 것이다.
  • 여기는 이해가 어려울 수 있는다, 그냥 예외가 발생하면 이를 처리하기 위한 함수가 있다고 생각하자
  • 그 함수의 시작 주소가 위에서 말하는 주소 혹은 벡터값으로 불린다.
  • 운영체제는 예외가 시작되는 주고를 보고 그 원인을 파악한다.
  • 만약 벡터화가 안되어있으면 위에서 소개한 상태 레지스터를 분석해야한다.

파이프라인 구현에서의 예외

• ID.Flush와 EX.Flush라는 것이 새로 생겼다.
  • 이는 예외가 발생했을 때, 그 이전의 모든 작업을 nop을 만드는 것을 돕는다.
• 중요한 것을 짚겠다.
  • PC에는 예외처리를 위한 벡터가 선택되어 들어간다. 이건 계산되는 것이 아니다.
  • EX.Flush는 EX 단계에서 예외가 생겼을 때, 그 결과가 MEM으로 넘어가서 저장되는 것을 막게된다.

    $ add $1, $2, $1 # 이 경우에 오버플로가 일어났다고 가정해보자
    $ or $3 $4 $3
    # 위의 경우 계산으로 인해 오버플로 예외는 발생하지만,
    # OS가 상황을 파악하기 위해서는(왜 오버플로가 일어났는지) 계산 결과를 $1에 저장하지 않고 본래 $1과 $2의 값을 유지해야 한다.  
    # (왜냐, 이 연산은 결과가 $1에 저장되어 계산에 사용된 본래 $1의 값이 사라질 가능성이 있다.)
    

  • 위의 예시를 중심으로 생각하면 EX.Flush로 인해 우리는 오버플로 상황을 파악하는 것이 가능하다. (계산 전에 어떤 값이 있어서 EX에서 예외가 발생했는지)
  • 그리고 우리는 예외가 발생한 명령어는 EPC(Exception Program Counter)에 저장한다. (원래는 PC+4가 저장되어 다음 명령어의 위치가 저장되어 버리니 처리할 때는 4를 빼서 확인해야 한다. 위의 예시에서는 or쪽 명령어의 위치가 저장된다. 근데 이건 예외가 발생한 위치가 아니자나)