7. 명령어 사이클과 인터럽트

📱명령어 사이클과 인터럽트📱

CPU는 기본적으로 메모리에 저장되어 있는 명령어를 순차적으로 처리한다.(일정한 주기,흐름이 있음)

-> 명령어 사이클

이러한 사이클을 끊는 신호를 인터럽트 라고 함.

 

명령어 사이클

프로그램 속 명령어들은 일정한 주기에 따라 반복되며 실행됨.

ex. 메모리로부터 CPU에 명령어를 가져오는 것 -> 인출 사이클 /  이를 실행 -> 실행 사이클 ...

인출 - 실행 - 인출 - 실행 ...

 

cf. 간접 사이클

간접 주소지정 방식

---

인터럽트

CPU의 흐름을 끊는 것이 인터럽트..

CPU가 빠르게 처리해야 하는 다른 작업이 생겼을 때 인터럽트가 발생함.

동기 인터럽트(exception)

에러핸들링이 자연스레 떠오르는 동기 인터럽트

---

비동기 인터럽트(하드웨어 인터럽트)

- 주로 입출력 장치에 의해 발생함.

하드웨어 인터럽트가 왜 필요한가?

입출력 작업 도중에도 효율적으로 명령어를 처리하기 위해서!

계속 물어볼 필요 없이, 작업이 다 되면 그냥 인터럽트 해버리는 것이 더 효율적임

인터럽트 요청 신호

CPU의 실행 사이클이 끝나면 항상 플래그 레지스터의 인터럽트 플래그를 확인함 -> 현재 인터럽트 요청을 받아들일 수 있는지 확인

* 모든 인터럽트를 인터럽트 플래그로 막을 수 있는 것은 아님! (대부분은 막을 수 있지만..)

---

CPU가 인터럽트 플래그를 확인하고 인터럽트를 받아들이기로 했다면

인터럽트 서비스 루틴을 실행한다.

 

인터럽트 서비스 루틴

인터럽트가 발생했을 때 해당 인터럽트를 처리하기 위한 '프로그램'

 

ex. 키보드가 인터럽트 요청을 보냈을 경우 ~이렇게 행동하라.

 

인터럽트 벡터

각각의 인터럽트를 구분하기 위한 정보

(인터럽트 서비스 루틴의 시작 주소를 알기 위한 정보)

인터럽트가 표의 형태로 모여있는 인터럽트 벡터 테이블도 메모리에 존재함.

 

인터럽트 요청 주체는 인터럽트 요청 신호 + 인터럽트 벡터를 데이터 버스를 통해 전달함.

---

'CPU가 인터럽트를 처리한다?'

-> 인터럽트 서비스 루틴을 실행하고, 본래 수행하던 작업으로 다시 되돌아온다.

(인터럽트의 시작 주소는 인터럽트 벡터를 통해 알 수 있음)

 

인터럽트 서비스 루틴 실행 전, 작업 과정을 스택에 백업해두는 것이 필요함.

인터럽트 서비스 루틴이 끝나면 원래 작업으로 리턴!

 

위 내용들을 합쳐보면 명령어 사이클은 아래와 같은 형태가 된다.

 

 

학습 출처: https://www.youtube.com/watch?v=bls_GjX-4U8&list=PLVsNizTWUw7FCS83JhC1vflK8OcLRG0Hl