※ 질문/내용오류/공유할 내용이 있다면 jinkilee73@gmail.com으로 메일 주세요 :-)

이제 어셈블리 언어에 대해서 이야기해보자.

우선 어셈블리 언어가 무엇인지 다시 한번 짚어보고 공부를 시작해보자.

우리가 하나의 C프로그램을 만든다. 

Preprocessing by preprocesssor (전처리 과정)

.C파일이 전처리 과정을 거치면 .i 파일이 나온다. .i파일은 100% 사람이 이해하기 쉬운 코드로서 .c파일과의 차이점은 단순히 #include <stdio.h>와 같은 부분이 실제 .h파일 내용으로 바뀌어져 있다는 것 뿐이다.

Compiler (컴파일 과정)

.i 파일이 이제는 기계어로 1:1 매칭될 수도 있고 사람이 이해할 수 도 있는 .s 파일로 바뀌게 된다. 이 것이 어셈블리 언어이다. 이것이 컴파일러에 의해 수행되는 과정이다.

Assembler

어셈블러가 .s파일을 기계어 코드로 매핑시켜준다. 중요한 것은 .s파일에 있는 모든 명령어는, 예를 들어 push %ebp 등등, 기계어와 1:1로 매칭된다는 점이다. 이 파일의 결과는 relocatable object file이다. 메모리의 어디든지 끼워맞출 수 있다는 뜻이다. 이게 무엇인지는 이전의 여러 포스팅에 거쳐서 굉장히 길게 자세하게 설명해놨으니 이전의 포스팅을 보도록 하자.

Linker (링킹 과정)

relocatable object file 형태를 가상 메모리로 매핑시키는 과정이다.

우리가 지금부터 공부할 부분은 컴파일 과정이 될 것이다.

보통 컴파일되어 생성된 .s파일은 다음과 같은 형태를 띈다.

제일 왼쪽의 숫자들은 이전의 포스팅에서 아주 자세하게 설명했다. 한번 더 짚고 가면, 저 숫자들은 실제 메모리가 아닌 가상메모리 주소이다. 즉, PC값이다. PC는 프로세스가 다음에 실행할 명령어의 주소를 가리킨다. "이 값이 PC라고? 가상메모리라고 그랬잖아요?" 라고 질문하는 사람들은 이전의 포스팅을 다시 한번 보자. 결국 그 말이 그 말이다. 가상 메모리 주소가 바로 CPU가 접근하는 메모리 주소이기 때문이다.

위의 어셈블리 코드가 실제로 어떻게 되어있는 것인지 아래 그림을 통해서 바이트 단위로 이해해보자. 가상 메모리에 아래와 같이 로드되어있는 것이다.

그 다음 알아야 할 것은 바로 레지스터이다. 레지스터는 CPU가 직접 direct로 접근할 수 있는 저장 장소이다. CPU에 있기 때문에 가장 빠른 속도로 접근이 가능하다. 레지스터는 속도가 빠르기 떄문에 그 양이 매우 적다. 컴퓨터 구조를 공부해본 사람은 알겠지만, 용량이 크면 클수록 보통 느리고 작으면 작을수록 빠르다. 레지스터는 무지하게 빠르게 접근이 가능하기 때문에 용량도 무지하게 적다. (빠른 것이 용량도 많아버리면 얼마나 가격이 비싸질까?)

CPU는 여러 종류의 레지스터를 가지고 있다. 그 레지스터가 어떤 종류가 있는지 알아보자.

CPU 내부는 다음과 같이 되어있다.

보면 우측 상단/하단에 Register file과 FP register 그리고 Condition Code와 PC도 있다. 이것들이 모두 레지스터들이다. 우리가 앞으로 자주 이야기할 레지스터들은 다음과 다음과 같다.

Application Programming Registers 들이 말 그대로 어플리케이션을 사용하면서 쓰게되는 레지스터들이기 때문에 이제부터 우리가 자주 보게 될 것이다.

우선 여기에서는 레지스터들의 이름을 읇어보고 그런 레지스터가 있다는 것 정도만 알아두자. 그리고 이 레지스터는 메모리나 하드디스크가 아닌 CPU에 있는 것이라는 것 역시 중요하게 알아둬야 한다.

자 이제 기본적으로 어셈블리언어를 공부하기 위해 알아두어야 할 것들은 모두 끝났다. 다음 포스팅부터는 진짜로 어셈블리 언어를 공부해보자.

※ 질문/내용오류/공유할 내용이 있다면 jinkilee73@gmail.com으로 메일 주세요 :-)

왜 요즘 컴퓨터들은 모두 Virtual Memory를 지원하는가? 왜 모두가 가상 메모리를 사용하고 있는 것인가? 오늘은 그것을 이야기 해볼 생각이다. 신난다. 사실은 이 얘기를 하고 싶어서 지금까지 몇 개의 포스팅을 써왔던 것이다. :-) 

근데 졸려-_-

지금까지 했던 내용과 그림들을 총동원해서 번개보다 빠르게 갈 것이니 잘 이해해보자.

프로그램을 실행하기 위해서 아마도 최초의 컴퓨터는 메모리의 고정 주소에 프로그램을 로드해서 썼을 것이다.(compile time binding) 그러다보니 메모리를 사용할 수 있는 공간의 범위가 조금 유연해졌으면 해서 relocatable object file, load time binding을 가능하게 했던 것이다.

위의 그림과 같다. 그런데 load time binding도 비효율적이드라. 무조건 연속적인 공간이 있어야 프로그램이 로드될 수 있다는 것이 매우 비효율적이라고 느껴졌던 것이다. 그래서 이를 효율적으로 사용할 수 있게 하기 위해서 execution time binding을 구현한 것이다. 실행시간 중에 메모리의 아무 공간에나 로드해라. 따라서 아래와 같이 가능하다.

각각의 프로그램이 분리되어 메모리어 로드되어도 실행가능하게 하는 것이다. 불연속적으로 로드되어도 실행가능하게 말이다. 이것이 가능하려면 특별한 하드웨어적 지원이 필요한데 그것이 MMU이다. 따라서 MMU가 logical address를 physical address로 변환해주는 역할을 하게 되는 것이다. 아래의 그림과 같다.

하나의 프로그램이 위와 같은 형태로 돌아가면 뭐가 좋은가? 우선 프로그래머 입장에서 코딩할 때 메모리 공간을 신경쓰지 않고 코딩해도 된다는 점이 좋다. 프로그래머가 "앗, 저 회사에서 메모리 1GB밖에 안 쓰는 PC가 있으면 어떻하지? 500 MB밖에 안 쓰는 PC도 있으면 어쩌지?" 이런 생각을 할 필요가 없게 만든다. 왜냐하면 왠만해가지고는 요즘 컴퓨터의 하드디스크 공간은 4GB는 넘는다.-_- 어짜피 연산을 수행하는 CPU가 실제로 접근하는 주소는 Virtual Memory이다. 따라서, 프로그래머로 하여금 "모든 컴퓨터는 4GB의 메모리 공간을 가지고 있다"고 생각하게 만들 수 있다. 프로그래머 입장에서는 사용자들의 메모리 성능 생각할 필요 없어서 좋다.

네? 어짜피 Virtual Memory이든 physical memory이든 load되는 프로세스의 크기는 똑같으니까 못돌리는 것은 매한가지 아니냐고요? 아니죠! dynamic loading입니다. 즉, 필요한 함수만 골라서 loading해서 쓰기 떄문에 프로그램의 크기가 실제 메모리보다 커도 실제로 메모리에 올라와 있는 공간은 작을 수 있죠.

에헴, 다시 독백모드로. 그래서 Virtual Memory를 쓴다. dynamic loading을 통해 실제로 쓰는 함수들만 호출할 수 있고 그것을 physical memory의 연속적이지 않고 불연속적으로 로드되어도 상관없게 만드므로서 실제 메모리 공간의 활용은 아래 그림과 같이 좋아진다.

이러다 보니 실제 메모리 공간에 올라와있는 프로그램의 수가 많아질 수밖에 없다. 당연하다. dynamic loading이 아니라면, 프로그램의 크기가 5MB, 5MB, 5MB짜리를 10MB의 메모리 공간에 돌릴 수 없지만, dynamic loading이 지원되는 환경에서는 5MB의 프로그램이 가령 3MB의 메모리 공간만을 차지하기 때문에(dynamic loading이란, 필요한 프로그램만 불러서 '알짜배기'로 쓰는 것이니까) 10MB의 메모리 공간으로도 총 15MB의 프로그램을 실행시킬 수 있다.

따라서 multi-programming degree가 높아진다. 여러 개의 프로세스가 메모리에 load되어있기 때문에 multi-programming degree는 당연히 높아지는 것이다.

Virtual Memory의 또 다른 장점은 바로 Swapping이다. 

http://operatingsystems.tistory.com/entry/SP-Virtual-Memory-Swapping

위의 링크에서 간단하게 언급만 하고 넘어갔다고 해서 무시하면 안 된다. Swapping을 하는 것은 사실 굉장히 시간이 오래 걸리는 작업이다. (CPU 입장) 따라서 Swapping하는 회수를 줄인다면 컴퓨터의 성능을 높일 수도 있다. Virtual Memory는 Swapping 회수를 줄여줄 수 있다. 왜냐하면 이것 역시 Dynamic loading이 전재되어있기 때문이다. Dynamic loading이 불가능하다면 메모리에 하나의 프로세스가 통째로 들어와야 하는데, 그렇게 되면 메모리의 활용가능한 공간은 당연히 줄어들 게 될 것이고, 활용가능한 공간이 줄어들면 활용가능한 공간을 만들기 위해 계속적으로 하드디스크와 Swapping을 해야하기 때문이다. (이 때 Swap 되는 하드디스크 영역을 Swap 영역이라고 한다.) Dynamic loading이 전재된 Virtual Memory 환경에서는 프로그램의 자주 사용되는 프로세스들이 알짜배기로 많이 로딩되어있기 떄문에 하드디스크와의 Swapping이 자주 발생하지 않을 수 있다.

아 개운하다. 지금까지가 내가 정말로 포스팅하고 싶었던 내용이다. 마지막으로 Virtual Memory의 장점을 아래와 같이 요약해보자.

1. 프로그래머 입장에서 쉽게 프로그래밍할 수 있다

2. Multi-programming degree를 높일 수 있다.

3. 메모리와 하드디스크간의 Swapping 회수를 줄일 수 있다.

이 포스팅부터 본 사람들은 아마 이해하기 힘드실 지도 모른다. 그런 분들께는 조심스럽게 이전에 포스팅해둔 [SP] Virtual Memory (Basic Knowledge) 부터 차례대로 공부해오시기를 권고한다.

※ 질문/내용오류/공유할 내용이 있다면 jinkilee73@gmail.com으로 메일 주세요 :-)

지금은 시스템 프로그래밍으로서의 Virtual Memory를 포스팅하고 있기 때문에 실제로 Virtual Memory를 구현한 기법인 Demand Paging과 같은 방법에 대한 소개는 안 할 예정이다. Virtual Memory에 대한 실제 개념만을 이야기해보자.

Virtual Memory를 제대로 설명한답시고 굉장히 여러 개의 포스팅을 사전지식으로 올려놨었다. 그것을 지금 활용해보고자 한다.

http://operatingsystems.tistory.com/entry/SP-Virtual-Memory-Basic-Knowledge-1

위의 포스팅에서 프로그램이 실제의 메모리에서 어떠한 방식으로 로드되는지 설명했다. 사람이 생각하기에는 그냥 메모리의 하나의 연속적인 공간을 프로그램이 다 차지하고 있으면 좋겠다. 그런데 컴퓨터 입장에서는 공간의 비효율이 생기기 때문에 연속적이지 않게 프로그램이 로드되는 것이 좋다고 했다. 이 내용이 위의 포스팅의 핵심 내용이다.

이런 생각을 했어야 한다. 실제 메모리에 연속적으로 프로그램이 로드되지도 않았는데 어떻게 프로그램이 실행될 수 있을까? 다음에 실행될 것이 어디있는 줄 알고? 그것에 대한 해답은 Virtual Memory로 할 수 있다. 32비트 컴퓨터 기준에서 OS 설치할 때 하드 디스크의 특정 공간에 4GB의 파일이 생성된다. 32비트 윈도우즈 7기준으로는 C:\pagefile.sys 라는 파일이 4GB의 용량을 차지하고 있을 것이다.

우선 CPU는 프로그램을 위의 공간에 연속적으로 로드시켜놓는다. 위의 공간의 주소에 연속적으로 놓여진 프로그램 명령어 즉,

8048040        push    %ebp

8048044        movl     %esp, %ebp

...                ...

이러한 어셈블리어 코드들이 차례대로 실행이 되는 것이다. 왼쪽에 있는 부분이 Virtual Memory라고 이해하면 되겠다. 이 주소들이 MMU에 의해 실제 Physical Memory주소로 변환되는 것이다. 따라서 실제 프로그램이 Physical Memory에서는 아무리 불연속적으로 로드되어있어도 상관이 없다. 왜냐하면 CPU는 Virtual Memory의 주소값으로 실행을 하는 것이기 때문이다. CPU가 메모리라고 생각하고 썼던 그것은(8048040과 같은 숫자들) 사실은 실제 Physical Memory의 주소가 아니었던 것이다. 일종의 가짜 주소이다. 그래서 Virtual Memory, 가상 메모리라고 부른다.

아래와 같이 그림으로 이해하면 쉽다.

물론 실제로는 push %ebp와 같은 것이 010001101..과 같이 사람이 읽을 수 없는 바이너리 표현으로 되어있겠지. 아무튼 위의 그림으로 충분히 이해할 수 있으리라고 믿는다. 마지막으로 설명을 다시 하면 CPU는 무조건 Virtual Memory를 통해서 실제 Physical Memory에 접근하게 되어있다. 

※ 이전의 링크를 참고해봐도 좋다. 

http://operatingsystems.tistory.com/entry/SP-Virtual-Memory-Basic-Knowledge

모든 프로그램들은 따라서 Virtual Memory에 우선적으로 로드되는 것이다 그 Virtual Memory에는 연속적으로 로드되는데 이것이 MMU에 의해 실제 메모리주소로 바뀌면서 실제 메모리 공간에 불연속적으로 로드되는 것이다. 

여기에서 Virtual Memory의 사이즈를 이야기 해보자. 앞서도 계속 32비트 기준이라는 말을 몇 번 했다. 32비트라 함은 실제로 다음과 같다.

0001 0010 1101 1100 1110 0011 1111 1100

0또는 1이 32개가 나열되어있는 것이다. 위의 Virtual Memory 공간은 2진수 0부터 2진수 1111...11 까지이다. 그것이 결국 몇 개인가? 2의 32승개이다. 

2의 32승 = 4,294,967,296

그런데 메모리 한 칸이 1 byte이니까 4,294,967,296 * 1byte = 4GB가 된다. 따라서 32비트 기준으로 가상메모리의 공간은 4GB가 된다. 64비트 컴퓨터면 엄청난 공간의 가상메모리를 사용할 수 있겠지요? 혹시 4GB라는 계산이 잘 이해가 되지 않는 사람은 아래의 그림을 참고해봐라.

짧게 다시 설명을 해보면, 가운데 55 89 e5와 같은 것은 하나하나가 1byte이다. 따라서 명령어 55는 메모리 한 칸을 차지하고 있는 것이고, 명령어 89 e5는 메모리 두 칸을 차지하고 있는 것이다. 따라서 89 e5다음의 명령어는 offset이 3이 되는 것이다. 결국 칸 수 체우는 것이지.

아무튼 다시 본론으로 돌아가보자. 32비트 컴퓨터에서 가상메모리의 한계는 결국 4GB가 된다. 다른 말로 말하면 하나의 프로세스의 크기는 32비트 컴퓨터에서는 4GB가 넘을 수 없다. 그런데 32비트 컴퓨터가 왜 4GB의 가상 메모리 공간을 하드디스크에 가지고 있는 것일까? 즉, 왜 가상 메모리를 쓰는 것일까? 다음 포스팅에서 설명해보자.