⭐️⭐️⭐️[CPU의 작동 원리] 명령어 사이클과 인터럽트

[1two13]

명령어 사이클(주기) 4️⃣

• CPU가 하나의 명령어를 처리하는 정형화된 흐름
  1. 인출 사이클: 메모리에 있는 명령어를 CPU로 가지고 오는 단계
  2. 실행 사이클: CPU로 가져온 명령어를 실행하는 단계
     • 제어장치가 명령어 레지스터에 담긴 값을 해석하고, 제어 신호를 발생시키는 단계
  3. 간접 사이클
     • 명령어를 인출하여 CPU에 가져왔더라도 실행 사이클을 실행할 수 없는 경우에 간접 사이클을 거친 후 실행 사이클 단계로 이동한다.
     • 실행 사이클을 실행할 수 없는 경우: 인출 사이클이 일어난 후 메모리 접근이 더 필요한 경우(인출 사이클 => 간접 사이클 => 실행 사이클 => 인출 사이클 => ...)
     • 오퍼랜드 필드에 유효 주소의 주소를 명시하는 간접 주소 지정 방식은 명령어를 인출하여 CPU로 가져왔다 하더라도 바로 실행 사이클에 돌입할 수 없다. 두 번의 메모리 접근이 필요하기 때문이다.(유효 주소의 주소 => 메모리 안에 있는 유효 주소 => 연산에 사용할 데이터)
  4. 인터럽트 사이클
     • 인출 사이클 => 실행 사이클 => 인터럽트 사이클 => 인출 사이클 => ...

p.137 그림 참고

[1two13]

인터럽트

• CPU의 작업을 방해하는 신호

인터럽트 종류 2️⃣

• 인터럽트의 종류를 구분하는 통일된 기준은 없지만 크게 두가지로 나뉜다.
  1. 동기 인터럽트(= 예외)
     • CPU에 의해 발생하는 인터럽트
  2. 비동기 인터럽트(= 하드웨어 인터럽트)
     • 주로 입출력장치(키보드, 마우스)에 의해 발생하는 인터럽트
     • 입출력 작업 중에도 CPU가 효율적으로 명령어를 처리할 수 있게 해준다.(CPU는 입출력장치로부터 완료 인터럽트를 받을 때까지 다른 작업을 처리할 수 있다.)
     • 알림 역할을 한다.

[1two13]

하드웨어 인터럽트 처리 순서

1. 입출력장치는 CPU에 인터럽트 요청 신호를 보낸다.
2. CPU는 실행 사이클이 끝나고 명령어를 인출하기 전 항상 인터럽트 여부를 확인한다.
3. CPU는 인터럽트 요청을 확인하고 인터럽트 플래그를 통해 현재 인터럽트를 받아들일 수 있는지 여부를 확인한다.
4. 인터럽트를 받아들일 수 있다면 CPU는 지금까지의 작업을 스택에 백업한다.
5. CPU는 인터럽트 백터를 참조하여 인터럽트 서비스 루틴을 실행한다.
6. 인터럽트 서비스 루틴이 끝나면 4에서 백업해 둔 작업을 복구하여 실행을 재개한다.

[1two13]

키워드 정리

• 인터럽트 요청 신호
  • 입출력장치가 인터럽트하기 전 CPU에게 끼어들어도 되는지 물어보는 신호
  • 인터럽트 요청을 수용하기 위해서는 플래그 레지스터의 인터럽트 플래그가 활성화되어 있어야 한다.
• 인터럽트 플래그
  • 하드웨어 인터럽트를 받아들일지, 무시할지 결정하는 플래그
  • 인터럽트 플래그가 가능으로 설정되어 있다면 인터럽트를 처리하고, 불가능으로 설정되어 있다면 요청을 무시한다.
  • 하지만, 모든 하드웨어 인터럽트를 인터럽트 플래그로 막을 수는 없다. 무시할 수 없는 하드웨어 인터럽트는 반드시 가장 먼저 처리해야하는 인터럽트로 정전이나 하드웨어 고장으로 인한 인터럽트가 있다.
• 인터럽트 서비스 루틴(= 인터럽트 핸들러)
  • 인터럽트를 처리하기 위한 프로그램
  • 인터럽트가 발생했을 때 어떻게 처리하고 작동해야 할지에 대한 정보로 이루어진 프로그램이다.
• 인터럽트 벡터
  • 수많은 인터럽트 서비스 루틴을 식별하기 위한 정보이다.
  • 인터럽트 벡터를 알면 인터럽트 서비스 루틴의 시작 주소를 알 수 있다.