[CS DAY5] - I/O : 키보드와 같은 장치들은 CPU 와 어떻게 통신하는걸까?

About this offer

우선, 지금까지 봤던 전체적인 흐름은 다음과 같다. Day 1 CPU → Fetch → Decode → Execute Day 2 CPU ↔ Cache ↔ RAM Day 3 CPU는 주소를 이용해 메모리에 접근 Day 4 CPU와 메모리는 Address / Data / Control 정보를 주고받음 주로, CPU 와 메모리에 대해서만 봤다. 하지만, 컴퓨터에는 메모리만 존재하는게아니라, 여러가지 장치들이 존재한다. 키보드 / 마우스 / 모니터 / USb ... 이런 장치들을 I/O ( Input / Output )Device, 입출력 장치 라고 한다. 오늘은, CPU 와 입출력 장치 ( 외부 장치)는 어떻게 데이터를 주고받을까? 에 대해서 알아보자. 우리가 키보드로 어떠한 문자를 친다고하자. 키보드 A 누름 ↓ 화면에 A 출력 하지만, 컴퓨터 입장에서는 여러가지 문제들이 있다. 우선, CPU는 키보드가 아니다. 키보드가 어떠한 방식으로 신호들을 만드는지를 CPU 가 다 알아야한다면, CPU 는 해야할일이 너무나도 많아진다. 즉, 외부장치와 CPU 의 연결고리? 역할이 필요하다. ( CPU 와 외부장치 사이에서 장치를 제어해주는 하드웨어 ) 이를 대표적으로, Device Controller 가 진행해준다. Device Controller CPU - 키보드 CPU │ ↓ Device Controller │ ↓ Keyboard CPU - 네트워크 장치 CPU │ ↓ Network Controller │ ↓ Network ... Device Controller -> 해당 장치와 관련된 제어를 담당한다. 그래서, CPU 는 외부장치가 어떻게 신호를 만드는지 알 필요가 없게된다. Device Controller 안에는, 어떤것들이 존재할까? 우선, 3가지를 먼저 알아보자. ┌─────────────────────┐ │ Device Controller │ │ │ │ Data Register │ │ Status Register │ │ Control Register │ └─────────────────────┘ Data Register 실제 데이터를 보관한다. ( 키보드 입력값, 네트워크에서 받은 데이터 ... ) Status Register 장치 상태를 나타낸다. ( READY, ERROR, BUSY ) 즉, 지금 작업이 가능한가를 나타낸다. Control Register CPU 가 외부 장치에게 어떤 작업을 시킬지를 전달한다. ( READ, WRITE, START ) ... 이는, Bus 에 대한것과 매우 비슷하게 느껴진다. Address Bus , Data Bus , Control Bus 아래와 같이 Java 프로그램에서, 키보드 입력을 받는 코드가있다. Scanner scanner = new Scanner(System.in); String input = scanner.nextLine(); scanner.nextLine() 을 통해, 사용자 입력을 받는 코드이다. 내부적으로는, 많은 일들이 일어난다. 사용자 ↓ Keyboard ↓ Keyboard Controller ↓ Device Driver ↓ OS ↓ JVM ↓ Java Program 이전에 봤듯이, CPU 의 처리속도는 굉장히 빠르다. 반면, 키보드는 CPU 에 비하면 매우 느리다. 또한, 사람이 키보드를 누르는 속도도 CPU 처리속도에 비하면 굉장히 느리다. 그럼 CPU 는 다음과 같은 과정들을 계속 진행해서, 입력값이 있는지 없는지를 계속 판단하는것일까? CPU: "키보드 입력 왔어?" 아니. "왔어?" 아니. "왔어?" 아니. "왔어?" 아니. "왔어?" YES. CPU가 계속해서, 장치 상태를 확인해보는것이다. 이를, Polling 방식이라고 한다. Polling 우선, 논리가 비교적 단순하다는것이다. ( 계속해서 확인하는거니까. ) 하지만, 문제가 있다. CPU 가 계속해서, "입력 왔음?" 이라는것을 확인한다. CPU 가 계속해서 이러한 것들을 확인한다고 하자. 그렇다면, CPU 는 시간을 낭비하게 된다. 이러한 시간을 낭비하지않고 다른것들을 하게된다면 Java 실행 와 같은 여러가지 일들을 처리할 수 있을것이다. 또한, 키보드는 자주 입력하지 않는 장치라고 볼 수 있다. 이러한 상황에서 키보드가 입력 되었는지를 확인을 Polling 방식으로 계속해서 한다면, CPU 입장에서는 굉장히 비효율적이다. 그렇기에, 해당 문제를 해결해야할 필요가 있다. 계속해서 CPU가 상태를 확인하는게아니라, 입력이 되었을때만 CPU 에게 알려주면 되는거아닐까? 이게, Interrupt 이다. Interrupt ? CPU 가 프로그램을 실행하고 있다고 하자. CPU Java 명령어 실행 ↓ 다음 명령어 ↓ 다음 명령어 ↓ 다음 명령어 CPU 는 자기가 해야할 일을 계속해서 하고있는것이다. 어느순간, 사용자가 키보드를 눌러서 값을 입력한다. Keyboard ↓ Controller ↓ "CPU야 입력 들어왔어!" ↓ Interrupt ↓ CPU Interrupt 를 통해 CPU는 이벤트가 발생했다는것을 알아챈다. 즉, CPU 는 필요한 시점에만, 해당 이벤트를 처리한다. Polling 방식에서는 Polling CPU → 장치 확인 CPU → 장치 확인 CPU → 장치 확인 CPU → 장치 확인 위와같이 CPU 가 계속해서 장치를 확인하는 방식이였다. Interrupt 를 통해서, CPU → 자기 일 하는 중 CPU → 자기 일 하는 중 CPU → 자기 일 하는 중 ← 장치가 알림! ( Interrupt) CPU → 이벤트 처리 위와 같은 과정으로 진행할 수 있다. DAY 1 에서, CPU 는 아래와 같은 방식으로 명령어를 처리한다고 했었다. PC ↓ Fetch ↓ Decode ↓ Execute ↓ PC ↓ 다음 명령어 CPU 가 명령어들을 실행하고 있던도중에, Interrupt 를 통해서 이벤트가 발생했다는것을 알았다. Program 실행 1000 ↓ 1001 ↓ 1002 ↓ !!! Interrupt !!! ↓ 키보드 처리 ↓ ??? CPU 가, 키보드 처리를 하고나서 ( 이벤트처리 ) 원래 명령어를 처리하던곳으로 돌아가야한다. 즉, 이벤트 처리전에 1002 까지 실행하고 있었기때문에, 이벤트를 처리하고 나서는 1002 다음을 실행해야한다. 그러기 위해서는, CPU 가 기존 실행 상태를 기억해야만 한다. 여기서, Register 상태 / Program Counter / Context 와 같은 개념들이 (다시) 등장한다.