기록을 남기자
작성일
2023. 3. 25. 22:46
작성자
ssun_bear
반응형

Program Execution

Fetch Stage

PC에 들어 있는 300은 Step1 이전에 있었던 것

PC에 300이 있다고 해서 우리가 메모리 300번지의 명령어를 읽어올수 없음

-> 내가 메모리에서 무언가를 읽어 오려면 내가 읽어 오려고 하는 명령 또는 데이터의 주소가 MAR에 있어야 함

 

Fetch Stage의 과정 

:메모리에서 300번지의 명령어를 읽어오는 과정

Fetch Stage 전 : PC : 300 / IR: 이전 실행 명령어가 들어있음

Fetch Stage
1. PC에 들어 있는 300의 주소를 MAR로 이동
2. PC++
3. 메모리 읽기
4. 메모리의 300번지 명령어가 MBR로 이동
5. MBR로 들어온 명령어를 IR로 이동

위의 과정에서 중요한 것은 PC의 값은 다음 명령어의 주소를 가리키도록 변경하는 것 : 따라서 PC값에 +1을 한다.

Fetch Stage
1. PC → MAR (읽어오려는 메모리 주소 옮기기)
2. PC++
3. memory read 명령 실행
4. 명령어 → MBR
5. MBR → IR

Execution Stage

Read

  1. IR의 Operation Code 확인
    어떤 명령을 시작하던지 간에 우선 명령을 분석해야한다.
    → 명령어에 따라 Execution Stage의 단계가 달라진다.
  2. IR → MAR
    Fetch Stage에서는 PC에 저장된 번지가 MAR로 이동을 했다면,
    Execution Stage에서는 IR에 저장된 번지가 MAR로 이동한다.
  3. MBR → AC(read) or AC → MBR(write)
    데이터를 읽어올 때는 Fetch Stage와 다르게 IR이 아니라 AC에 데이터를 저장한다.

Instructions

  1. 0001(1) = Load AC from memory(읽어오기)
    메모리 → AC
  2. 0010(2) = Store AC to memory(저장하기)
    AC → 메모리
  3. 0101(5) = Add to AC from memory(더하기)

위의 세 명령어는 모두 데이터가 이동하는 명령어이다.

 

cf) 데이터가 이동하는 명령어

  1. Processor-memory data transfer
  2. Processor-I/O data transfer
  3. Data processing
    산술논리연산 명령어(+, -, and, or)

cf) 데이터가 이동하지 않는 명령어

  1. Control
    jump 명령어, 조건을 확인한 후 주소 번지 이동시키는 명령어
    데이터가 필요 없는 명령어이다.
    ⇒ 모든 명령어가 데이터가 필요한 것은 아니다.

Instruction Register

Read IR

메모리 940번지에 있는 수를 읽어와서 AC에 넣어라 (Load)
  1. IR의 Operation code 확인 = 1
    어떤 명령을 시작하든간에 우선 명령을 분석해야한다.
  2. IR → MAR
    IR의 주소 (1을 빼고 940번지만) MAR로 이동
    데이터를 가져오려면 또 몇번째 주소에 있는지 알아야하므로 MAR에 IR주소 부분이 이동
  3. memory load
    여기선 read(이번엔 data 이동)
  4. memory → MBR
    MAR의 데이터가 MBR로 이동
  5. MBR → AC
    데이터를 읽어올 때는 Fetch Stage와 다르게 IR이 아니라 AC에 데이터를 저장한다.

Add IR

메모리 941번지에 있는 수와 AC에 있던 수를 더해 AC에 다시 넣어라(Add)
  1. IR의 Operation code 확인 = 5
    AC 에 있는 내용(3)과 941번지에 있는 데이터(2)를 덧셈을 하라는 명령
  2. IR → MAR
    941번지에 있는 데이터를 가져와야 하니깐 941번지의 IR의 주소를 MAR로 이동
  3. memory read
  4. memory → MBR
    941번지의 데이터가 MBR로 이동, MBR에는 2라는 데이터 저장
  5. MBR → (AC + MBR) → AC
    실제로는 레지스터가 무지하게 많기 때문에 이런식으로 계산 안한다.

Store IR

메모리 941번지에 AC에 있는 수를 저장해라(Store)
  1. IR의 Operation code 확인 = 2 (명령분석)
    AC에 저장된 값을 941번지에 다시 저장하라는 명령
  2. IR → MAR
    데이터를 쓸때는 읽을때와 달리 몇번지에 무슨내용을 쓸지 이야기 해줘야 한다.
    MAR에는 주소를, MBR에는 그 번지에쓸 내용을 이야기 해줘야함
    IR의 주소(941번지)를 MAR로 이동
  3. AC → MBR
    번지에 쓸 내용은 AC에 있으므로 AC에 있는 내용을 MBR로 이동
  4. memory write
  5. MBR → memory

이렇게 명령 하나를 실행하는데 CPU의 여러 레지스터들이 작동하면서 작업이 이루어지고,

Condition Codes, Interrupt Enable/Disable, Supervisor/user mode에 해당하는 비트가 바뀌게 된다.

이렇게 프로그램이 작동한다.


Interrupts

CPU가 명령어를 한줄 한줄 실행하고 있을 때 중단하는 것

 

3가지 관점의 Interrupt

1. 내가 프로그램 일때 

A라는 어플리케이션 프로그램일 때, 10번째 명령어까지 실행하고 갑자기 중단 됨
→ 나는 무슨 일이 생겼는지 모름
→ 이후 시간이 흐르고 11번째 명령어부터 다시 실행
→ 중단
→ 재개
...

2. 내가 OS일 때

(전체 시스템 관점에서)
A를 실행하다가 A를 중단
→ OS 실행 (중단, OS가 프로그램을 바꾸는 역할을 한다.)
→ B 실행
→ OS 실행 (중단)
→ A 실행
...

 

3. 내가 CPU일 때

CPU는 프로그램 A가 실행되고 있는지, B가 실행되고 있는지, C가 실행되고 있는지 모른다.
→ 그저 한줄 한줄 명령어를 실행할 뿐, 이 한줄 한줄의 어떤 프로그램의 명령어인지는 모른다.

그러나, App이 실행되고 있는지 OS가 실행되고 있는지는 알아야한다.

  • OS가 실행되고 있을 경우에는 컴퓨터의 많은 자원에 access할 수 있지만,
  • 다른 기본 App들은 매우 한정적으로 access할 수 있기 때문이다.
OS가 프로그램을 CPU(프로세서)에게 뺏고 주고 하는 것이다.

 

Interrupt의 4가지 종류

1. Program Interrupt

프로그램의 명령어가 한줄한줄 실행되다가
이 명령어 한줄의 실행결과와 관련된 다양한 하드웨어가 Interrupt를 거는 것
-> 프로그램에서는 인터럽트를 다룰수 없음 (주의)

Program Interrupt가 발생하는 명령

  1. Overflow
    Condition 명령어에서 발생할 수 있다.
  2. division by zero
    잘못된 연산
  3. Illegal mechine instruction
    CPU의 IR OP code 분석
  4. reference outside a user's allowed memory space
    CPU는 access 가능한 메모리 영역을 표시해두어서 그 영역을 넘어가는 번지수를 요청할 때 Interrupt를 걸 수 있다.

2. Timer Interrupt

시스템 내 CPU는 한개이기 때문에 한개의 App만을 실행하는 것은 비효율적
-> 각 프로그램 마다 실행할수 있는 시간이 정해져 있다 
동시에 여러 프로그램들이 실행되는 것 처럼 보이게 된다

OS가 나타나서 프로그램을 다른 것으로 바꾼다

3. I/O  Interrupt

I/O Controller가 발생시키는 Interrupt

추후 뒷 내용에서 자세히 설명하겠음

4. Hardware failure Interrupt

하드웨어에 문제가 발생해서 프로그램을 다 멈추고 OS가 문제를 해결하는 것

대부분의 I/O Devices은 프로세서(CPU)보다 속도가 느림
⇒ 프로세서 입장에서는 입력과 출력을 기다리는 것이 거의 천년만년이다..
장치를 위해서 멈추고 있으면 너무 CPU라는 장비가 아깝게 되는 것이다..


Program Flow of Control with or Without Interrupts(1)

메모리 ↔ CPU ↔ buffer ↔ I/O modules  

Write = Print

외부에서 입력을 받으면 입출력 모듈은 buffer에 입력 받은 값을 저장

이 내용을 CPU를 통해 Main Memory로 이동

Write은 CPU가 하는 것이 아님 

CPU는 I/O Device에게 입출력을 하라고 지시만 한다. (I/O Command)

 

  • (4) : 입력을 하든, 출력을 하든 I/O buffer를 사용해야한다. 
    출력을 한다면 내가 출력한 내용들이 메모리안에 있을 것( 몇번지에 있는 내용들을 I/O buffer로 전부 이동)
    그 다음 출력을 요청

I/O Command 실행 → 입력 받기

  • (5) : 입출력이 끝나면 끝이 아니라 return 등을 통해 입출력이 성공적으로 이루어 졌는지 확인을 해서 user 프로그램에게 알려준다.
    (성공여부 확인 작업까지 해야 입출력 작업이 완전히 끝나게 된다.)

1 - 4 --------- 5 - 2 - 4 -------- 5 - 3 - 4 -------- 5
→ 줄이 긴 것은 CPU가 노는 시간이다.
⇒ 시간이 너무 아깝기 때문에 인터럽트를 사용하게 된다.

 

 

(b) 4번 내내, I/O가 입력을 받는 시간 내내 기다리지 않고 바로 돌아와서 다른 프로그램을 실행하는 것

 

  • (1): user 프로그램 실행
  • (4) 입출력 준비작업
  • (2a) : 원래는 입출력 준비를 하기 위해 놀고 있는 시간을 줄이기 위해 (2a)부분 실행 -> interrupt가 걸리면 (5) 실행
  • (5) : 입출력이 제대로 걸렸나 확인
  • (2b) : 작업 마저 이어서
  • (4) : (2b)작업을 마치고 다시 입출력을 하게되면 (4)작업 실행
  • (3a) : 원래는 입출력 준비를 하기 위해 놀고 있는 시간을 줄이기 위해 (3a)부분 실행 -> interrupt가 걸리면 (5) 실행
  • (5) : 입출력이 제대로 걸렸나 확인
  • (3b) : 작업 마저 이어서

1 - 4 -2a - 5 - 2b - 4 -3a- 5 - 3b

⇒ 더 빠르다

 

I/O Interrupt

다른 프로그램을 하다가 I/O 작업이 끝나면 작업이 끝났다고 인터럽트를 보내는데, 이것이 I/O 인터럽트이다.
이는 Interrupt Handler가 제어한다.

.

Timing Diagram : Short I/O Wait

 

Interrupt Handler

왼쪽 그림이 user program, 오른쪽 그림이 Interrupt Handler이다.

  1. Interrupt Handler는 OS의 한 부분이다.
  2. Interrupt Handler는 Interrupt가 발생하면 Interrupt를 처리하는 역할을 한다.
  3. 모든 항목마다 적절한 Interrupt Handler가 따로 존재한다.

Interrupt Handler 실행되는 과정

  1. user program이 i번째 명령어까지 실행
  2. interrupt
  3. 실행하던 프로그램 종료
  4. Interrupt Handler 프로그램 실행
  5. Interrupt Handler가 아까의 5번(입출력 성공여부 확인)까지 실행
  6. 다시 i+1 코드 실행

Q. Interrupt가 걸려도 왜 바로 처리를 하지 않을까?

Fetch Stage → Execute Stage → Interrupt Stage

왜 Fetch, Execute 이후에서야 Interrupt가 처리될까?

Interrupt가 처리된 이후에는 PC가 복귀가 되어 PC에 저장된 다음 명령어가 실행되기 때문에 이전 명령어는 처리가 완료되어야 있어야 한다.
Instruction cycle Fetch-Execute이 진행되면 PC가 증가되어 버리기 때문에 완료되지 않은 상태에서 인터럽트가 진행되고, PC가 복구되면 이전 명령어는 진행되지 못하게 된다.

 

Instruction Cycle with Interrupts

하나의 프로그램의 사이클의 아니다.

 

Execute Stage가 끝날 때마다 Interrupt가 걸렸는지 확인한다.
Interrupt가 왜 걸렸는지 누가 걸었는지를 확인해야한다.
해당하는 Interrupt Handler를 실행한다.

 

Initiate Interrupt Handler

 

Q. Interrupt Stage에서는 Interrupt가 걸린 이유를 파악하고 이 Interrupt Handling 하기 위한 적절한 프로그램을 실행시킨다. → X

Interrupt Stage에서는 프로그램을 실행시킬 수 없다.

명령 하나를 실행시키는 사이클이다.
따라서 Interrupt Handler라는 새로운 프로그램을 시작해야하기 때문에
결국 Interrupt Stage에서는 OS를 실행시킨다.

⇒ OS 실행

 

Q. OS의 실행 순서?

PC 값 OS 명령어로 변경하기

 


Program Flow of Control with or Without Interrupts(2)

 

 

(b) I/O 작업이 굉장히 오래걸리는 경우

1,4 : 유저 프로그램이 진행되다가 아까와 마찬가지로 I/O요청 

마찬가지로 write으로 돌아와서 작업을 하는데 2번 진행 할때 까지 interrupt가 걸리지 않음

I/O작업이 굉장히 오래걸리기 때문에 2번 작업을 다 할때 까지 끝나지 않는 것

실제로 I/O작업이 빨리 끝나는 작업이 아니라 굉장히 오래걸리는 작업이다..

그렇기에 2번작업이 끝마치고 다음번 write 작업 등장

 

첫번째 출력의 경우 출력을 요청해놓고 돌아와서 다음작업 실행

두번째 출력의 경우 아직 끝나지 않기 때문에 계속 기다리고 한참 기다리다보면 언젠가는 끝남

그래서 두번째 write에서 한참 기다리다가 다 끝나서 interrupt가 걸려서 그때 interrupt handler가 나타나서 5번 작업 실행 그 다음 두번째 write 출력 작업을 요청

interrupt는 작업을 조금씩 당겨서 했기에 시간은 조금 빨라졌지만 여전히 낭비되는 시간이 있다.

그래서 이제 대부분의 경우 I/O작업이 괸당히 긴 시간을 거쳐서 이루어져 (CPU는 ns/s , I/O작업은 초단위로_

사실은 프로그램을 바꾸어 버린다. 프로그램을 진행하다가 지금 나와있는 그림처럼 기다리는 것이 아니라 다른프로그램을 실행한다.

 

+) user 프로그램 실행하다가 write 명령이 나오면 write 요청 실시

write에 관한 함수를 I/O프로그램이 찾는다. 그리고 나서 다른 프로그램을 실행

한참 있다가 프로그램이 진행 되다가 어느 순간 interrupt가 걸리는데

이 I/O작업이 끝났다고 하는 Interrupt는 내가 요청한 Interrupt가 아닌 것이다.

다른 프로세스가 전에 요청했던 Interrupt가 되는 것이고 그래서 이렇게 I/O작업이 이뤄지고 I/O작업이 굉장히 시간이 많이 걸려 Interrupt가 발생한다


Program 바꾸기

Q. OS 실행 방법은 ?

OS도 프로그램이기에 A 실행 -> Interrupt -> OS -> B 실행

 

PC에 OS 실행 명령어 주소를 저장
PC의 값을 바꾸면 프로그램이 바뀔수 있음

Interrupt 이후 이어서 실행을 해야하므로 OS로 프로그램을 변경하기 전

메모리는 안전하기 때문에 중단된 명령어들(CPU값)을 모두 레지스터에 저장한다.


Simple Interrupt Processing

 

 

HardWare

  1. CPU가 처리
  2. Device Controller가 인터럽트 발생(I/O)
  3. 지금 실행하고 있는 명령어는 끝까지 처리한다.
    Fetch 과정에서 PC가 증가하게되는데 Execute 처리가 되지 않고 Interrupt가 실행되고 PC가 복구되면 이전 명령어는 실행되지 않는다.
  4. CPU가 인터럽트 인지
  5. CPU가 PSW와 PC값 control stack(안전한 메모리, 하드웨어)에 저장
  6. PC에 OS 실행 주소 번지 저장

SoftWare

OS 또는 Interrupt Handler가 처리
OS는 어마어마하게 큰 프로그램, 시스템을 관리하는 프로그램이다.

Hardware와 Software가 만나는 부분이 굉장히 많은데 그걸 OS가 처리한다.

  1. 나머지 중요한 CPU 정보들, process state를 저장
  2. 인터럽트가 왜 발생했는지 확인 후 적절한 처리
  3. process state CPU 복구
  4. PC, PSW 복구

Q. PC, PSW 따로 저장하는 이유?

마지막에 process state 먼저하는 이유?
새로 실행을 시작할 PC 값을 저장하는 순간 인터럽트 핸들러의 작업이 끝나기 때문이다.
새로운 프로그램이 바로 시작되어 버린다.
이전의 중요한 정보들이 모두 저장되지 못한채로 새로운 프로그램이 시작된다.
OS가 해야할 것을 먼저 끝내고 다른 프로그램이 시작되어야한다.

따라서 Hardware에서도 5번 이후 6번이 실행되어야 한다.
6번에선 이미 PC 가 OS 주소로 바뀌기 때문이다.

 

반응형