04-3 명령어 사이클과 인터럽트
04-3 명령어 사이클과 인터럽트
CPU가 메모리의 명령어를 실행하는 데는 정해진 패턴, 흐름이 있다. 이 흐름 또는 주기를 명령어 사이클이라고 한다.
근데 간혹 이 정해진 흐름을 끊기도 하는데, 이 흐름을 끊는 신호를 인터럽트라고 함.
명령어사이클: 인출>실행>인출>실행>인출..반복
1. 인출 사이클: 가장 먼저 메모리에 있는 값을 CPU로 가져와야한다. 이를 인출이라 함
2. 실행 사이클: CPU에 가져온 값을 실행함
근데 인출 이후 메모리 접근이 더 필요한 경우가 있다(오퍼랜드는 주소필드라고도 불린다는 점!) → 1.5 간접사이클
1. 인출 사이클
1.5 간접 사이클
2. 실행 사이클
인터럽트: CPU가 꼭 주목 또는 먼저 처리해야할 다른 일이 생겼을 때
- 인터럽트 종류: 동기 인터럽트(예외), 비동기 인터럽트(하드웨어 인터럽트)
동기인터럽트(exception)
- CPU가 예기치 못한 상황을 접했을 때 발생
- 예) 메모리 갔더만 원하는 데이터가 없거나 실행할 수 있는 명령어가 없거나 디버깅..등
비동기 인터럽트: 주로 입출력장치에 의해 발생
- 알림 같은 거임
ㄴ 예1) 프린터가 CPU에게 "나 프린트 다했어!"
ㄴ 예2) 키보드가 CPU에게 "타이핑 발생했어!"
- 왜 있는거임?? 일반적으로 입출력 장치의 입출력 작업은 CPU에 비해 느림 → (인터럽트 없다면)cpu가 입출력 작업 완료 여부 확인을 주기적으로 해줘야함...그래서 인터럽트 둬서 CPU가 굳이 계속 확인할 필요 없도록 하기 위해 인터럽트 사용
인터럽트 처리 순서 (=인터럽트 서비스루틴을 실행하고 본래 수행하던 작업으로 다시 돌아오는 과정+그리고 인터럽트 시작 주소는 인터럽트 벡터를 통해 알 수 있다)
1. 입출력장치 > CPU 인터럽트 요청 신호 발송: 입출력장치가 cpu에게 말한다 "지금 끼어들어도 됨?"
2. CPU가 실행 사이클 끝내고 명령어 인출 전 항상 인터럽트 여부 확인.
3. CPU가 인터럽트 요청 확인 후 인터럽트 플래그를 통해 현재 인터럽트를 받을 수 있는지 확인
ㄴ플래그 레지스터에서 인터럽트 받아들일 수 있는지 확인하는 값. 이걸로 CPU가 이렇게 얘기할 수 있는거임 "지금은 안되요~장사 안해요~"
ㄴ 근데 모든 인터럽트를 인터럽트 플래그로 막을 수 있는 건 아님. 긴급한 건이라면 이 플래그값 상관없이 인터럽트 들어가기도 함(Non Maskable Interupt)
4. 인터럽트 받아들일 수 있다면 CPU는 지금까지 작업 백업
5. CPU는 인터럽트 벡터(인터럽트를 구분하기 위한 정보) 참조해 인터럽트 서비스 루틴 실행
ㄴ 인터럽트 서비스 루틴마다 메모리에서 차지하는 주소가 달라..그니깐 인터럽트 벡터 값을 통해 CPU가 인터럽트 서비스루틴을 메모리의 어디서부터 시작하면 되는지 알 수 있음
6. 인터럽트 서비스 루틴(메모리 안에서 실행되는 프로그램) 끝나면 (4)에서 백업해 둔 작업 복구 후 실행 재개
ㄴ 인터럽트 서비스 루틴은 인터럽트가 발생했을 때 어떻게 처리하면 좋을지 적혀있는 프로그램이라 생각하면 됨(like "키보드 타이핑에는 이렇게 행동하세요")
ㄴ 근데 어떻게 복구함? 기존에 레지스터에 있던 값들을 어디 보관? → 지금까지 작업내용은 stack(메모리 내 스택 영역)에 백업해놓음.
출처