[반os] 시스템구조 & 프로그램 실행

컴퓨터 시스템 구조

 

컴퓨터가 I/O device에서 인풋을 받으면 처리해서 아웃풋을 보냄

 

■ 메모리

ㅡ> CPU의 작업공간

ㅡ> CPU는 매 쿨럭 사이클마다 메모리에서 인스트럭션을 읽어서 실행

 

■ 입력장치

ㅡ> 키보드, 마우스

 

■ 출력장치

ㅡ> 프린터, 모니터

 

■ 하드디스크

ㅡ> I/O장치로도 볼 수 있다

ㅡ> data를 메모리로 읽어들이기 (input)

ㅡ> 처리결과를 디스크 파일 시스템에 저장 (output)

 

CPU와 입출력장치의 속도차이는 어마어마하다

■ Controller

ㅡ> 메모리 컨트롤러

ㅡ> 디바이스 컨트롤러

ㅡ> DMA 컨트롤러

 

I/O device

■ device controller

ㅡ> I/O장치는 그 장치들을 전담하는 작은 CPU같은 것들이 붙어있다

 

■ local buffer

ㅡ> CPU에 Memory가 필요하듯이, device controller에도 작업공간이 필요하다

ㅡ> 그것이 local buffer

CPU

■ Register

ㅡ> CPU안에, 메모리보다 빠르면서 정보를 저장하는 작은공간

 

■ Mode bit

• 1 (사용자 모드) : 사용자 프로그램 실행
• 0 (모니터 모드) : OS코드 실행

ㅡ> 지금 CPU에서 실행되는 것이, OS인지 사용자 프로그램인지 구분해줌

ㅡ> 보안을 헤칠 수 있는 명령어(instruction)는 모니터 모드에서만 실행

ㅡ> interrrupt/Exception 발생시 하드웨어가 Mode bit을 0으로 전환

ㅡ> 사용자 프로그램에 CPU를 넘기기전에 mode bit을 1로 세팅

 

■ Interrupt line & Timer

1. Time sharing

ㅡ> OS가 CPU제어권을 프로그램에 넘겨줄 때, 타이머를 설정해둔다 

ㅡ> 만약 프로그램이 무한루프에 걸리면 타이머에서 타임아웃이 발생한다

ㅡ> 그럼 타이머가 interrupt line에 보고한다

ㅡ> CPU는 매번 Insruction 실행한 뒤 intrrupt line을 확인한다

ㅡ> 거기서 타임아웃을 발견하면, CPU자원이 프로그램에서 OS로 넘어간다

2. I/O 입력

ㅡ> 키보드에 입력이 들어오거나 디스크에서 읽어오는 작업이 끝나면 버퍼에 저장하고, 디바이스 컨트롤러가 interrupt를 건다

ㅡ> interrupt가 들어오면 CPU가 OS로 넘어가고, OS는 왜 interrupt가 왔는지 확인한다.

ㅡ> 해당 I/O 요청을 했던 프로그램의 메모리에 버퍼의 내용을 복사한 뒤, CPU를 interrupt 당한 프로그램한테 다시 돌려준다

 

 

 

ㅡ> CPU는 메모리에서 계속 다음 instruction을 읽어와서 실행하는 작업만 한다 

ㅡ> instruction중에는, scanf나 printf처럼 I/O장치를 써야하는 작업이 있다

ㅡ> 그걸 CPU가 직접 하는게 아니라, 해당 디바이스 컨트롤러한테 시키고 CPU는 하던일 계속한다

ㅡ> 사용자 프로그램B가 I/O장치의 응답을 기다리고 있으면, CPU는 그동안 쉬는게 아니라 다른 프로그램에 할당된다

ㅡ> CPU는 메모리와만 일하는데, 키보드 입력이나, 디스크한테 읽어오라고 한게 다 읽어왔다던지 하는 것은 어떻게 알까?

Mode bit

Timer

Device Controller

Control register

ㅡ> cpu가 일을 시킬때 그 제어정보

 

Memory controller

ㅡ> 메모리를 담당하는 컨트롤러

 

DMA controller

ㅡ> 디바이스 버퍼 매번 읽으면 CPU에 인터럽트가 너무 많아서, DMA가 대신 버퍼를 메모리로 복사해주고 CPU에 보고만 함

입출력(I/O)의 수행

특권 명령 : 모니터 모드(mode bit = 0)에서 실행

 

사용자 프로그램이 직접 못하니, 시스템콜을 통해 OS한테 부탁함

사용자 프로그램이 mode bit 1인 상태에서 작업하다 시스템콜로 interrupt를 걸어서 mode bit을 0으로 바꿈

그리고 OS가 I/O명령을 대신해줌

인터럽트

사용자 프로그램

ㅡ> 소프트웨어 인터럽트로 OS에 I/O명령 요청을 한다

I/O장치

ㅡ> 일을 완료하면 하드웨어 인터럽트로 CPU에 알린다

 

소프트웨어 인터럽트

ㅡ> = 트랩

ㅡ> Exception : 프로그램 오류 

ㅡ> System call : 커널 함수 호출

 

인터럽트 벡터

ㅡ> 인터럽트 처리 루틴의 시작 주소를 저장하는 테이블 또는 배열

 

인터럽트 처리 루틴(ISR)

ㅡ> 인터럽트 발생시 실행하는 코드or 함수

시스템콜

사용자 프로그램이 interrup line을 만들고

그럼 CPU 제어권이 OS로 감

동기식 vs 비동기식 입출력

 

동기식 (synchronous)

ㅡ> 프로그램이 I/O 끝날 때까지 기다림

 

비동기식 (asynchronous)

ㅡ> 프로그램이 I/O한테 일 시키고 그동안 다른일 함

DMA

DMA controller

ㅡ> 디바이스 버퍼 매번 읽으면 CPU에 인터럽트가 너무 많아서, DMA가 대신 버퍼를 메모리로 복사해주고 CPU에 보고만 함

ㅡ> blcok 단위로 복사하고 인터럽트

 

(빠른 입출력장치일수록 인터럽트가 빈번해서 DMA가 필요)

서로 다른 입출력 명령어

좌측그림

ㅡ> 일반적인 I/O

ㅡ> 메모리에 접근하는 instruction과 I/O에 접근하는 instruction이 다름

 

우측그림

ㅡ> Memory Mapped I/O

ㅡ> I/O장치도 메모리주소의 연장주소를 붙여서 접근함

저장장치 계층 구조

위로갈수록 빠르지만 비싸서 용량이 작음

위에 연두색은 휘발성, 아래 분홍색은 비휘발성 매체

 

CPU가 직접 접근하는곳은 Primary (바이트단위 접근)

직접 접근 못하는 곳은 Secondary (섹터단위 접근)

 

캐시 메모리

ㅡ> CPU와 메인메모리의 속도차이를 완충

ㅡ> 필요한 것만 아래서 위로 올려서 씀 (재사용 목적)

프로그램의 실행(메모리 load)

파일 시스템의 실행파일 실행하면, 메모리에 올라가서 프로세스가 됨

사실 피지컬 메모리에 바로 올라가는게 아니라, 중간에 버츄얼 메모리단계를 거침

 

0번지부터 시작하는 그 프로그램만의 독자적인 주소공간이 생김(code, data, stack)

ㅡ> code : 기계어 코드

ㅡ> data : 변수, 자료구조

ㅡ> stack : 함수 호출, 리턴할 때 데이터를 쌓았다가 꺼냄

 

이걸 물리적인 메모리에 올려서 실행을 시키는 것

다 올리는게 아니라, 당장 필요한 것만 올리고 필요없으면 디스크 swap area에 내림

(커널 영역은 항상 올려져 있음)

 

버츄얼 메모리와 피지컬 메모리의 주소 번지가 다르다

ㅡ> 주소 변환을 해주는 하드웨어 장치가 있다

커널 주소 공간의 내용

 

data

ㅡ> 운영체게가 사용하는 여러 자료구조들

ㅡ> 하드웨어 종류마다 자료구조를 하나씩 만들어서 관리하는 것을 추상적으로 그려놓은 그림

ㅡ> PCB : 실행된 프로그램을 관리하기 위해 프로그램 각각 부여되는 자료구조

 

stack

ㅡ> 운영체제도 함수구조여서 함수호출할 때 스택이 쌓임

ㅡ> 사용자 프로그램마다 스택공간을 따로 부여

사용자 프로그램이 사용하는 함수

함수의 3가지 종류

ㅡ> 사용자 정의 함수

ㅡ> 라이브러리 함수

ㅡ> 커널 함수

 

사용자 정의 함수와 라이브러리 함수는 프로그램 안에 정의가 되는데

커널 함수는 프로그램 안에 없어서 시스템 콜을 해야한다

프로그램의 실행

프로그램 A가 실행되며 모드가 전환되는 모습