컴파일 관련 용어 정리

#1 컴파일 이야기

#1-1 프로그래밍이란

프로그래밍은 인간의 사고와 의도를 기계(CPU)가 이해하고 수행할 수 있는 형태로 번역하는 과정이다.

 

#1-2 소스 코드 (Source Code)

인간의 사고와 의도를 기계가 오해 없이 이행할 수 있도록, '컴파일'을 염두에 둔 여러 약속(계약)에 맞춰 쓴 글.

 

#1-3 컴파일 (Compile)

먼저 소스 코드가 지켜야 할 약속을 검사한 다음 소스 코드에 담긴 글쓴이의 의도를 보존하면서 (상대적) 고급 언어를, (상대적) 저급 언어로 변환하는 것.

 

예시

예1: example.c → example.s
예2: example.s → example.o
예3: example.c → example.o
예4: example.java → example.class

 

CPU와의 관계

컴파일은 궁극(최종)적으로 CPU가 실행할 코드를 생성하려는 목적의 행위다. 반대로 말해, CPU가 이 세상에 존재하지 않는다면 컴파일 또한 존재 의미를 잃는다.

 

#1-4 링킹 (Linking)

컴파일된 코드들을 서로 어떻게 연결할지 확정한 다음, 프로그램 시작 지점(entry point)을 정의하는 등의 여러 추가 작업으로 실행 가능한 프로그램으로 완성하는 것. 실무에서는 링킹이 컴파일에 포함된 개념인 것처럼 말하기도 한다.

 

예시

// main.c 파일

int add(int, int);   // 선언만 있음

int main() {
    int result = add(1, 2);
    return result;
}

---
// add.c 파일

int add(int a, int b) {
    return a + b;
}

main.c와 add.c를 각각 컴파일해서, 각각 main.o와 add.o로 만들 수 있다. main.o와 add.o를 재료로 링킹을 수행하면 실행 가능한 프로그램(가령 example.exe)이 튀어나온다.

 

예시처럼 링킹의 재료가 2개가 아니라 1개인 경우는 어떨까? 링킹이 필요 없을까? 아니다. 링킹은 참조 관련 작업만 수행하는 게 아니고, 프로그램 시작 지점 정의와 같은 여러 세부 작업을 수행하기 때문이다.

 

#2 바이너리 이야기

#2-1 이진 데이터와 바이너리 코드

binary: (형용사) 2진법의 

바이너리는 2진법이라는 의미다. 즉, 0과 1만 쓴다는 말이다.

 

이진 데이터
= binary data
= binary (바이너리)

이진 데이터는 '0과 1로 표현된 정보'를 의미한다. 예를 들면 cㆍjava 등의 소스 코드 파일, class 파일처럼 컴파일은 했지만 아직 바이너리 코드는 아닌 코드, JPGㆍMP3 등 각종 파일, 동굴 벽에 새겨진 "01011010..." 등이 있다. 소스 코드는 텍스트 형태이므로 이진 데이터가 아니라고 생각할 수 있다. 하지만 어떤 문자도 디스크와 메모리에 저장될 때 결국 0과 1로 인코딩되어 저장되기 때문에 이진 데이터다. 이진 데이터를 '바이너리'라고 부르기도 한다.

 

바이너리 코드
= binary code, binary language
= 기계어

어떤 CPU가 '직접 실행할 명령'으로 받아들이는 이진 데이터(CPU에 그대로 때려박았을 때 CPU가 정상 작동해야하는 코드)를 의미한다. '기계어'라고 부르기도 한다. 예를 들면 x86 기계어, x86-64 기계어, 8086 기계어 등이 있다. 바이너리 코드는 #1-3에서 말한 '저급 언어'의 '극단'이다.

 

#2-2 바이너리 코드의 표기 형식

이진수(bit string) 표현 방식

0100110010...

0과 1을 비트 단위(bit-level)로 나열한 방식이다.

 

16진수(hexadecimal) 덤프 표현 방식

b8 78 56 34 12...

이진수(bit string) 표현을 8비트마다 끊어서, 16진수 2자리로 표현한 것이다. 바이너리 코드까지 디버깅해야 하는 프로그래머들의 가독성 증대를 위한 형식이다. 8비트마다 끊는 게 왜 가독성 향상에 도움이 될까? CPU가 바이너리 코드를 해석하는 단위인 word가 일반적으로 byte(= 8bit)의 배수이기 때문이다. word가 byte의 배수로 설계된 이유는 #3-1에 나온다.

 

#2-3 ISA (Instruction Set Architecture, 명령어 집합)

방금, CPU가 명령으로 받아들이는 이진 데이터를 바이너리 코드라고 했다. 여기서 명령으로 받아들인다는 말은, 일관성이 존재한다는 말이기도 하다. 당연하겠지만, CPU에 어떤 바이너리 코드 A를 어제 넣었을 때와 오늘 넣었을 때 동일하게 작동해야 할 테니 말이다.

 

그 일관성 있는, (CPU가 따라야 할) 명령 체계를 ISA라고 한다. ISA는 여러 종류가 있으며 CPU마다 실행 가능한 ISA가 다르다. 가령 덧셈 연산을 하는 명령어, CPU가 보유한 어떤 레지스터에 어떤 값을 저장하라는 명령어 등은 같은 ISA라면 반드시 똑같고, 다른 ISA라면 다를 수 있다.

 

#2-4 ABI (Application Binary Interface, 프로그램 이진 인터페이스)

복수의 코드들을 각각 컴파일할 때, 각 컴파일 산출물이 CPU에서 서로 일관성 있게 호환되게 만들기 위한 규약이다. 이게 무슨 말일까? CPU 입장에서 생각하면 쉽다. CPU는 "어떤 함수를 처리한 다음 그 함수의 반환 값을 어떤 레지스터에 저장해야(must) 하는가?" 따위의 규칙이 없다. 특정 레지스터에 어떤 값을 저장하는 명령어(⊂ ISA)는 있겠지만, 그건 당위(must)와는 아무런 연관이 없다. 즉 CPU라는 '공용 공간'에서 지켜야 할 규칙을 적어 놓은 게 ABI다. 바이너리 코드 A와 바이너리 코드 B의 ABI가 서로 다르면 둘 다 CPU를 제멋대로(?) 사용할 테고, 당연히 A와 B는 상호작용(호환)이 불가능할 것이다.

 

ISA에 종속된 ABI

예를 들어 어떤 ABI에서는 코드 속에 표현된 함수 호출 시 첫 번째 매개변수를 RDI 레지스터, 두 번째 매개변수를 RSI 레지스터에 넣고, 나머지 인자들은 CPU 밖 메인 메모리의 스택 영역에 순서대로 배치, 함수의 반환값은 RAX 레지스터에 받는다는 내부 규칙을 지닌다. 

 

여기서 어떤 ABI든 특정 ISA에 종속된다는 사실을 알 수 있다. ISA 별로 레지스터 이름과 개수, 레지스터 또는 메모리에 무언가를 저장하는 명령, 계산 명령 등이 전부 다를 것이기 때문이다. 다시 말해, ABI가 보유하는 여러 세부 규칙은 특정 ISA의 구조와 명령을 기반으로 정의되기 때문이다.

 

ABI에 종속된 컴파일

그렇다면 '컴파일' 또한 'ABI'에 종속적이라는 이야기가 된다. 컴파일은 궁극(최종)적으로 CPU가 실행할 코드를 생성하려는 목적의 행위이므로, 그 최종 산출물(기계어)이 CPU에서 잘 돌아가야만 한다. 따라서 (해당 CPU의 ISA를 지원하는) ABI에 맞춰 컴파일되어야 기계어가 올바르게 실행될 것이다.

 

실제로도 그렇다. 아래는 example.c를 example.s로 컴파일하는 터미널 명령어다.

gcc -S example.c -o example.s -m32

이 명령어는, 명령어가 실행되는 플랫폼(Window, Linux, ...)의 ABI를 그대로 따라간다. 하지만, 

gcc -S example.c -o example.s -m32 -mfastcall

처럼 ABI 옵션을 명시하면 해당 ABI에 맞춰 컴파일된다. 당연하겠지만, 첫 번째 터미널 명령어로 생성된 example.s와 두 번째 터미널 명령어로 생성된 example.s는 서로 다른 파일일 것이다.

 

#3 바이트 이야기

#3-1 바이트의 탄생

기원

1956년 IBM에서 근무하던 Werner Buchholz는 '컴퓨터마다 고정된 크기의 비트 묶음'을 의미하는 'byte'라는 용어를 창시했다. 이때 byte의 목적은, 문자(character)를 담는 최소 주소 단위를 표현하기 위함이었다.

 

구체 개념으로의 변모

가령 byte가 n개의 비트로 이루어진다면 1byte는 총 2n 개의 가짓수를 지니는 문자들을 표기할 수 있다. 1byte는 1964년 전까지 6bit, 7bit, 12bit 등 각양각색이었다. 1964년 출시된 IBM 360이 대성 공을 거두면서, IBM 360가 사용했던 1byte = 8bit가 널리 퍼지게 되었다. 그 때문에 1byte는 8bit를 의미하는 대명사로 굳어졌다. byte = "비트 묶음"이라는 추상 개념이, "8비트 묶음"이라는 구체 개념으로 변모한 것이다.

 

산업에 끼친 영향

이에 맞춰 메모리 산업도 변했다. 바로, 메모리에 접근하는 최소 주소 단위를 8bit (1byte)로 둔 것이다. (IBM 체계에서) 문자 하나가 1byte이므로, 메모리 주소 하나에 문자 하나가 꼭 맞게 들어가기 때문이다. 이렇게 byte는 범용 데이터 표현 단위로 (사실상) 고정되었다. 더 나아가 byte라는 '표현 단위의 표준'은, (메모리·파일·네트워크·명령어 인코딩 등의) '최소 교환 단위의 표준'으로도 자연스럽게 이어졌다. 이 시점부터 "파일을 읽는다"라는 게 'byte 스트림'(byte들의 연속된 나열)을 받는다는 말과 동의어가 되었다.

 

#3-2 VM (Virtual Machine, 가상 머신)

VM은 1970년대에 등장했다. 당시의 소프트웨어들은 특정 기계에 강하게 종속되었다. 하드웨어 사양(ISA, ABI 등) 등이 달랐기 때문에, 같은 소스 코드를 기계마다 다시 컴파일해야 했다. 때문에 소프트웨어의 이식성과 호환성을 증대시켜야 한다는 필요가 생겼고, 이를 충족하기 위해 VM이 등장했다.

 

VM이란 물리적인 하드웨어가 아닌, 소프트웨어로 구현된 '추상적인 실행 환경'을 의미한다. 단순화해서 설명하자면 VM은 일종의 'CPU 대행'(추상화된 CPU)이다. 가상 ISA, 가상 레지스터 등을 보유하기 때문이다. 특정 물리적 하드웨어의 상세 사양을 직접 신경 쓰지 않고, 프로그램의 의도에 집중할 수 있다. 즉, VM이 제공하는 추상화된 하드웨어 환경만 이해하면 된다.

 

#3-3 바이트 코드 (Byte Code)

가상 머신에 입력할 코드를 의미한다. 초기에는 바이트 코드를 'intermediate code'라고 불렀다. CPU의 ISA를 따르지 않는 코드지만, VM이 알아서 ISA로 변환할 코드이므로 중간 매개(intermediate) 역할의 코드라는 뜻으로 말이다. 그러다가 점차 byte code라는 이름으로 불렸는데, VM이 intermediate code를 byte 단위로 '해석'(≠ 읽음)하기 때문이다. 그런 VM에 넣을 code이기에 byte code인 것이다.

 

여기서 말하는 '해석'은, 데이터를 메모리로부터 읽어 들이는 걸 의미하는 게 아니다. byte(= 8bit) 단위로 읽어 들이는 것은 VM이 등장한 시점에서는 이미 업계의 표준이었기에, 단순히 "byte 단위로 읽는다"라는 이유만으로 byte code라 명명되었다고 보기는 어색하다 (이런 식이면 소스 코드를 바이트 코드라고 불러도 되어버린다!). 해석은 이미 읽어 들인 데이터에 의미를 부여하는 규칙의 문제다. 

 

그렇다면 VM은 왜 byte code 단위로 해석하는가? 전 문단에서 '해석'을 강조하기 위해서 '읽음'을 배제했다면, 여기서는 전적으로 '읽음'을 강조해야한다. 읽는 단위와 해석 단위를 일치시키면 별도의 조합ㆍ정렬 과정 없이 입력을 곧바로 명령어로서 해석할 수 있다. 이는 VM의 성능을 향상시킨다. '읽음' 단위 → '해석' 단위 변환 계층이 없는 단순한 구조에서 오는 높은 속도 덕분이다.