티스토리 뷰

3.1 A Historical Perspective

x86이라고 불리는 Intel 프로세서 라인은 긴 발전적인 개발이 있었다.

높은 성능과 더 발전된 운영체제를 지원하기 위한 요구에 맞게 기술적인 향상에 이점을 띄었다.

 

Intel의 프로세서는 8086 -> Pentium -> Core i7 등으로 발전하였다.

Intel은 그들의 프로세서 라인에 다양한 이름을 갖고 있다.

Intel Architecture 32-bit의 IA32이고 최근에는 Intel64로 x86-64로 불리고 있다.

 

많은 회사들이 인텔 프로세서와 호환 가능한 프로세서들을 생산하였다.

이 중의 최고는 AMD(Advanced Micro Devices)이며 늘 Intel에 기술적으로 뒤쳐졌으며 시장 점유율에서도 밀렸다.

(최근에는 AMD가 엄청나게 부흥 중..)

 

무어의 법칙(Moore's Law)

 

3.2 Program Encodings

p1.c와 p2.c라는 파일을 생성하고 유닉스 명령어 줄에서 컴파일하려면:

$ gcc -Og -o p p1.c p2.c

 

gcc는 GCC C 컴파일러를 가리킨다.

-Og는 최적화의 단계를 적용하려는 컴파일러를 가리킨다. 높은 수준의 최적화는 무겁게 바뀌는 코드를 생성해서 생성된 기계 코드와 원래 소스 코드 사이의 관계를 이해하기 어렵다.

 

gcc 명령어는 소스 코드를 실행 가능한 파일로 바꾸는 프로그램을 만든다.

첫 번째, C 전처리기는 #include로 명시된 파일들을 포함시켜 소스코드를 확장하고 #define으로 명시된 매크로(macro)로 확장한다.

두 번째, 컴파일러는 p1.s와 p1.s의 이름을 갖는 어셈블리 코드를 생성한다.

그 다음에, 어셈블리 코드는 p1.o와 p2.o의 이진 오브젝트 코드 파일로 변환한다.

마지막으로, 링커가 구현된 라이브러리 파일과 두 오브젝트 코드 파일을 병합시켜 실행 가능한 파일 p를 생성한다.

 

3.2.1 Machine-Level Code

컴퓨터 시스템은 다양한 다른 형태의 추상화를 사용한다.

기계 수준 프로그래밍에서 두 가지가 특히 중요하다.

첫 번째, 기계 수준 프로그램의 형식과 동작은 명령어 집합 구조(instruction set architecture: ISA)에 의해 정의된다.

프로세서 상태, 명령어의 형식를 정의하고 각각의 명령어가는 상태에 미치는 효과를 정의한다.

프로세서는 많은 명령어를 동시에 실행하려고 매우 정교한 하드웨어이지만, 모든 동작을 ISA에 의해 설명된 순차적인 연산을 매치하는 것을 확실하게 하기 위해 보호 수단을 사용한다.

 

두 번째, 기계 수준 프로그램에 의해 사용된 메모리 주소는 가상 주소이다.

메모리 시스템의 실제 구현은 다양한 하드웨어 메모리와 운영 체제 소프트웨어의 결합과 연관이 있다.

 

어셈블리 코드 표현은 기계 코드와 매우 비슷하다.

기계 코드의 이진 형태보다는 읽을 수 있는 형태로 되어 있다.

 

C가 메모리에 선언되고 할당되는 다른 데이터 타입의 오브젝트 모델을 제공해주는 반면,

기계 코드는 메모리를 큰 바이트-어드레스할 수 있는 배열이다.

 

프로그램 메모리는 프로그램에 대한 실행 가능한 기계 코드와 운영 체제에 의해 요구된 정보, 프로시저 호출과 반환를 관리하는 런타임 스택,

사용자에 의해 할당된 메모리 블럭을 포함한다.

프로그램메모리는 가상 주소를 사용하여 어드레스된다.

운영체제는 가상 주소 공간을 관리하고, 가상 주소를 실제 프로세서 메모리에 있는 물리 주소로 번역한다.

 

3.2.2 Code Examples

다음과 같은 코드를 작성한다:

#include <stdio.h>

long mult2(long, long);

void multstore(long x, long y, long *dest) {
	long t = mult2(x, y);
	*dest = t;
}

 

$ gcc -Og -S mstore.c 명령어로 컴파일하면 mstore.s 어셈블리 파일이 생긴다.

mstore.s 어셈블리 파일

코드의 각 줄은 단일 기계 명령어에 대응한다.

pushq는 레지스터 %rbx의 내용이 프로그램에 푸시된다를 가리킨다. (책에서는 %rbx 였다..)

 

-c 명령어 옵션을 사용하면 $ gcc -Og -c mstore.c

 

이는 이진 형태의 오브젝트 파일 mstore.o를 생성하여 직접적으로 보지는 못한다.

여기서 중요한 것은 기계에 의해 실행된 프로그램은 명령어 시리즈로 인코딩된 간단한 바이트 시퀀스이다.

 

기계 코드 파일의 내용을 보려면, 디셈블러(disassembler)라고 불리는 프로그램이 중요하다.

이 프로그램은 기계 코드로부터어셈블리 코드와 비슷한 형태를 생성한다.

리눅스 시스템에서, OBJDUMP 프로그램은 -d 플래그와 함께 제공한다.

 

$ objdump -d mstore.o

mstore.o 디셈블러 코드

왼쪽에는 앞에 보여준 14개의 16진수 바이트를 볼 수 있으며 1 ~ 5바이트 그룹으로 나누었다.

책에서는 ‘53 48 89 d3 e8 00 00 00 00 48 89 03 5b c3’ 시퀀스를 0: 1: 4: 9: c: d: e:으로 나누었다.
각각의 그룹은 오른쪽에 보여진 어셈블리어와 같은 단일 명령어이다.

 

--- 디셈블리어 표현 - 다시

 

실제 실행 가능한 파일을 생성하는 것은 main함수를 포함한 오브젝트 코드 파일에 대한 링커 실행을 요구한다.

#include <stdio.h>

void multstore(long, long, long *);

int main() {
	long d;
	multstore(2, 3, &d);
	printf("2 * 3 --> %1d\n", d);
	return 0;
}

long mult2(long a, long b) {
	long s = a * b;
	return s;
}

위 코드를 작성하고 $ gcc -Og -o prog main.c mstore.c로 prog 실행 가능한 파일을 생성한다.

prog 파일은 8,655 바이트가 되며 디셈블할 수 있다.

 

디셈블한 코드는 mstore.c의 디셈블리에 의해 생성된 것과 거의 동일하다.

prog dissembly code

첫 번째 다른 점은 왼쪽에 있는 주소가 다르다는 것이다. 링커가 이 코드를 다른 범위의 주소로 시프트했다.

두 번째 다른 점은 링커가  callq 명령어가 mult2라는 함수를 호출할 때 사용하는 주소를 입력했다.

마지막 다른 점은 nop이라는 명령어이다. 이 명령어는 반환 명령어 이후에 나타났기 때문에 프로그램에 아무 영향이 없다.

 

3.2.3 Notes on Formatting

GCC에 의해 생성된 어셈블리 코드는 사람이 읽기 어렵다.

'.'으로 시작하는 줄은 어셈블러와 링커를 안내하는 지시문이다. 우리는 일반적으로 무시한다.

명령어가 무엇을 하는 지나 어떻게 코드와 연관되어 있는 지에 대한 설명이 있는 설명이 없다.

 

어셈블리 코드의 더 깔끔 설명을 제공하기 위해, 줄 번호와 설명이 있는 주석을 포함하는 반면, 대부분의 지시문을 생략한다.

 

3.3 Data Formats

32-비트로 확장된 16-비트 아키텍쳐의 기원으로 인해,

인텔은 워드(word)를 16-비트 데이터 타입으로 사용한다.

 

32-비트는 "double words", 64-비트는 "quad words"로 말한다.

x86-64에서 C 데이터 타입의 크기

위의 표는 x86-64에서 사용되는 C의 원시적인(primitive) 데이터 타입이다.

포인터는 64-비트 기계에서는 8바이트 쿼드 워드로 저장된다.

 

x86-64 명령어 집합은 바이트, 워드, 더블 워드에 대한 완전한 명령어를 포함한다.

 

부동 소수점 수는 두 가지 원리 형태로 온다.

단일 정밀도(4바이트) 값은 float로, 2배 정밀도(8바이트) 값은 double로 온다.

 

GCC에 의해 생성된 대부분의 어셈블리 코드 명령어는 수치 크기를 표시하기 위한 하나의 접미사를 가지고 있다.

예를 들어, 데이터 이동 명령어는 4가지 경우가 있다.

movb(move byte), movw(move word), movl(move double word), movq(move quad word)

댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
TAG
more
«   2025/01   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함