>>> 터보 C의 깊은 곳 <<< 제5회 어셈블리 코드 접속 II Assembly Code Interface II 글/임인건 (서울대 기계공학과4) --------------------------------------------------------------------- 1 본문에 앞서 --------------------------------------------------------------------- 저번 회에는 어셈블리 코드와 C 루틴과의 접속(interface)을 위해 어 셈블리 모듈쪽에서 과연 어떠한 조치가 취해져야 하는가에 관한 몇 가지 규칙들을 상세히 알아보았다. 이번 회에는 계속해서 다음 사항에 대하여 알아보도록 하자. 1. 다른 모듈에 정의되어 있는 외부명칭(함수명 및 변수명)의 참조 2. C 모듈에서 어셈블리 모듈의 함수 호출 3. (실)매개변수의 참조 4. 자동변수의 정의 및 참조 5. 어셈블리 모듈에서 C 모듈의 함수(라이브러리 포함) 호출 6. 어셈블리 모듈의 어셈블 방법과 최종적인 링크 방법 --------------------------------------------------------------------- 2 대형 데이터 모델과 스택 세그먼트의 크기 --------------------------------------------------------------------- 소형 데이터 모델에서는, 스택의 크기를 결정하는 외부변수 _stklen과 근거리 힙의 크기를 결정하는 _heaplen 둘 중 어느 하나의 초기치가 0일 경우에, 스택 세그먼트의 크기가 정확히 64K바이트로 결정된다. 실제로 _s tklen의 내정된 초기치는 4096이고 _heaplen의 초기치는 0이기 때문에 스 택 세그먼트는 64K바이트의 크기를 가진다(물론 공유되는 데이터 세그먼트 도 포함해서). 반면에 대형 데이터 모델에서는 근거리 힙이란 게 없으므로 _heaplen 변수가 존재하지 않는다. 따라서 (데이터 세그먼트와 분리된) 스택 세그먼 트는 정확히 _stklen의 초기치만큼의 크기를 가지게 된다. 이 때 _stklen 의 내정된 초기치가 4096이므로 그 크기는 4K바이트가 되는 것이다. 결과적으로 대형 데이터 모델에서는, 프로그램쪽에서 _stklen의 초기 치를 다른 값으로 지정하지 않는 한, 스택은 4096바이트라는 협소한 크기 를 가지게 된다. 이 때 만약 수 킬로 바이트에 달하는 덩치 큰 자동배열을 정의하거나 과다한 재귀 호출(recursive call)을 수행하거나 하면, 스택 포인터 레지스터 SP가 스택 세그먼트 하위 경계를 넘어가 다시 0xffff부터 감소하게 되는 아주 치명적인 사건이 발생한다. 사실 SP가 0xffff부터 다시 감소하더라도 그 영역은 원거리 힙 영역이 므로 겉으로 보기에는 별 일이 없을 것이다. 하지만 동적으로 메모리를 할 당하거나 spawn... 함수 또는 system 함수를 호출하여 도스로 잠시 나갈 일이 생기면, 프로그램으로 되돌아올 때의 복귀번지가 파괴되어 나중에 복 귀할 때 프로그램이 그대로 폭주해 버리는 일이 터진다. 말로만 할 게 아니라 직접 확인해 보이겠다. 다음의 <예제 1>이 그것 이다. 반드시 대형 데이터 모델(예컨데 대형 모델)에서 컴파일/링크시키기 바란다. <예제 1> 대형 데이터 모델과 스택 세그먼트의 크기 --------------------------------------------------------------------- #include #include void main(void) { SP의 값을 가지는 의사변수(pseudo variable)---+ printf("_stklen is %u, SP is currently %u\n", _stklen, _SP); } --------------------------------------------------------------------- 실행 결과 _stklen is 4096, SP is currently 4072 --------------------------------------------------------------------- --------------------------------------------------------------------- 3 다른 모듈에 정의되어 있는 외부명칭의 참조 --------------------------------------------------------------------- 3.1 외부명칭의 선언 다시 본론으로 되돌아가서, 이번에는 다른 모듈(주로 C 모듈)에 정의 되어 있는 외부명칭을 어셈블리 모듈에서 참조하는 방법에 대해 설명하겠 다. 알고 있으리라 믿지만, 참조(reference)란 변수에 저장되어 있는 값을 읽거나 변수에 값을 저장하거나 또는 함수를 호출하는 등의 명칭에 관련된 모든 "직접적인" 행위를 총칭하는 말이다. 우선 요구되는 것은 EXTRN 지시자(directive)에 의한 외부명칭의 선언 이다. 이것은 C에서의 선언 개념과 제법 유사하다. 일단 EXTRN 지시자에 의해 올바르게 명칭이 선언된 후에는 다른 내부명칭 참조하듯이 할 수 있 다(이후 "EXTRN 지시자"는 편의상 "EXTRN문"으로 약칭하겠다). 외부명칭에 속하는 것은 크게 두 가지이다. 하나는 외부변수이고 다른 하나는 외부함수이다. 여기서 외부함수란 정적함수를 제외한 다른 모든 일 반적인 함수를 뜻한다. 우선 EXTRN문의 문법을 살펴보자. [ ]는 생략 가능함을 뜻한다. 그리 고 어셈블리쪽에서는 EXTRN문에 의한 "정의"라는 표현을 쓰지만 우리는 C 를 배우고 있으므로 그에 맞춰 "선언"이라는 용어를 쓰겠으니 착오없기 바 란다. EXTRN 선언[, 선언] ...... 이 때 "선언"은 다음과 같은 문법 구조를 가진다. 명칭:형[:개수] 명칭은 물론 변수나 함수의 이름이다. 형(type)은, 변수일 경우 그 바 이트 크기, 함수일 경우 호출 거리(근거리/원거리)를 지정한다. 개수(coun t)는 명칭이 배열과 관련될 때, SIZE나 LENGTH 지시자의 결과를 올바로 구 하기 위하여 선택적으로(optional) 지정한다. 배열이 아닌 일반적인 변수 라면 개수는 1일 것이므로 생략하면 된다. 사실 SIZE 지시자 등을 쓸 일이 없으면 생략해도 무방하다. C에서도 배열의 선언에서는 (첫번째;맨좌측) 배열크기를 생략할 수 있지 않은가? 다시, EXTRN문으로 하나의 명칭만을 선언한다면 문법은 다음과 같이 간단해진다. 명칭 앞에 추가적인 밑줄이 덧붙는 이유는 지난 달에 이미 설 명했다. 즉 C쪽에서 extvar라면 어셈블리쪽에서는 _extvar라고 해야 한다. 안 그러면 링크할 때 친근한(?) Undefined symbol이라는 에러를 만나게 될 것이다. EXTRN _명칭:형 예) EXTRN _extvar:WORD EXTRN문으로 명칭을 선언할 때에는 다음의 세 가지 사항에 매우 유의 해야 한다. 어셈블리어 초보자들의 경우는 세번째 사항에 특히 신경을 써 야 할 것이다. [1] 명칭의 변수명인가 함수명인가? [2] 명칭의 형을 올바로 선언했는가? [3] 명칭을 올바른 위치에서 선언했는가? 3.2 외부명칭의 형(type) 먼저 첫번째와 두번째 사항에 대해 설명하겠다. 터보 어셈블러의 경우 EXTRN문에 지정할 수 있는 형은 다음 <표 1>과 같다. <표 1> 형명과 관련된 C 데이터형 +----+----------+------+--------------------------------------------+ | | 형명 | 크기 | 관련된 C 데이터형 | +----+----------+------+--------------------------------------------+ | 함 | NEAR | | 근거리 함수 | | 수 | FAR | | 원거리 함수 | | 명 | PROC | | 근거리 또는 원거리 함수* | +----+----------+------+--------------------------------------------+ | | BYTE | 1 | char, unsigned char | | 변 | WORD | 2 | int, unsigned, 근거리 포인터 | | | DWORD | 4 | long, unsigned long, 원거리 포인터, float | | 수 | FWORD | 6 | 없음(80386용 48비트 원거리 포인터) | | | PWORD | 6 | 없음(80386용 48비트 원거리 포인터) | | 명 | QWORD | 8 | double | | | TBYTE | 10 | long double(터보 C 2.0 이상) | | | DATAPTR | 2/4 | 근거리 또는 원거리 포인터** | | | 구조체명 | ?? | 각종 구조체(structure) | +----+----------+------+--------------------------------------------+ * .MODEL 지시자에 따라 자동으로 그 바이트 크기가 결정된다. ** 거대 포인터는 C 수준에서만 지원된다. 이 중에서 PROC와 DATAPTR은 무척 유용한 것이지만 .MODEL 지시자를 써야 의미가 있으므로 다음 달로 설명을 미루겠다. 그리고 QWORD나 TBYTE 는 부동형 데이터와 관련되므로 거의 쓰이지 않고, FWORD나 PWORD는 80386 에서나 쓰이는 것이므로 신경 꺼도 된다(48비트짜리 포인터 써 본 사람 있 으면 손 좀 들어 보시오!). 마지막로 어셈블리쪽에서는 구조체와 같은 복 잡한 데이터형을 다룰 일이 거의 없다. 결국 우리가 관심을 가져야 할 것 은 다음 5가지로 압축된다. [1] 함수명일 때: NEAR, FAR [2] 변수명일 때: BYTE, WORD, DWORD 예를 들어 소형 데이터 모델에서 다음과 같이 외부변수로 "정의"되어 있는 변수들은, int i = 0, array[10]; char c, *s = "turbo28"; --- s는 근거리 포인터 long fp = 1000L; char near *nearptr, far *farptr; | | | +----- 원거리 포인터 +----------------- 근거리 포인터 어셈블리쪽에서 아래와 같이 EXTRN문을 써서 선언한 뒤 참조하면 된 다. EXTRN문에서는 여러 명칭들을 쉼표로 구분하여 나열할 수도 있지만, 설명의 편의상 한 줄에 하나씩만 선언했다. EXTRN _i:WORD +---개수 10은 생략해도 별 지장 없음 EXTRN _array:WORD:10 EXTRN _c:WORD EXTRN _s:WORD --- 명시적으로 near/far 수식자가 지정되어 있지 않으므로 DATAPTR을 쓰는 게 더 바람직하지만 메모리 모델이 고정적이라면 아무래도 상관없다. EXTRN _fp:DWORD EXTRN _nearptr:WORD -+- 명시적으로 near/far 수식자가 지정되어 EXTRN _farptr:DWORD -+ 있으므로 DATAPTR를 쓰면 안 된다. 참고로 위의 선언에서는 각 명칭들이 부호있는 데이터형인지 부호없는 데이터형인지 전혀 구별되지 않는다. 따라서 부호가 있는지의 여부는 실제 로 변수를 참조하는 곳에서 어떤(부호쓰는?부호안쓰는?) 어셈블리 명령을 쓰느냐에 달려 있다. 다음으로 소형 코드 모델에서 다음과 같은 원형(prototype)을 가지는 (외부)함수들은, void memset(char *dest, int value, int n); void near nearmemset(char near *dest, int value, int n); void far farmemset(char far *dest, int value, long n); 어셈블리쪽에서 아래와 같이 선언한 뒤 호출하면 된다. 물론 호출하려 면 호출 관행 등에 대한 규칙도 준수해야 하는데 그것은 뒤에 계속 설명하 겠다. EXTRN _memset:NEAR --- near/far가 명시적으로 지정되어 있지 않으므로 PROC를 쓰는 게 더 바람직하지만 메모리 모델이 고정적이라면 아무래도 상관없다. EXTRN _nearmemset:NEAR --- 명시적으로 near/far 수식자가 지정되어 EXTRN _farmemset:FAR --- 있으므로 PROC를 쓰면 안 된다. 위에서 함수의 매개변수(parameter)나 반환값(return value)에 관한 정보가 완전히 무시되어 있다는 점에 유의하기 바란다. 3.3 외부명칭의 선언 위치 원칙은 간단하다. +------------------------------------------------------------------+ | EXTRN문은 해당 명칭이 존재하는 세그먼트 범위 내에 위치해야 한다. | | (PUBLIC문도 마찬가지이다.) | +------------------------------------------------------------------+ 예를 들어 만약 외부변수라면 거대 모델이 아닌 한 초기화의 여부에 따라 _DATA 또는 _BSS 세그먼트에 존재할 것이므로 해당 EXTRN문도 그 세 그먼트 범위(SEGMENT∼ENDS) 내에 놓여야 한다. 그리고 (외부)함수의 경우 에 소형 코드 모델에서는 당연히 _TEXT 세그먼트 내에 존재할 것이므로 해 당 EXTRN문도 그 세그먼트 내에 놓여야 한다. 여기서 조심할 것은 만약 해 당 세그먼트에 속하는 코드가 모듈 내에 전혀 출현하지 않는다 하더라도 그 EXTRN문을 위해서 해당 세그먼트를 마련하여야 한다는 점이다. 앞 절의 예에서는 다음 <예제 2>와 같이 EXTRN문만을 위한 세그먼트를 마련하고 그 안에 두면 될 것이다. 나머지 실제적인 코드 및 데이터 세그 먼트는 그 이후에 놓으면 된다. 어차피 동일한 명칭의 논리 세그먼트는 여 러 군데에 분리해 놓더라도 나중에 링커에 의해 하나로 합쳐지니까 말이 다. <예제 2> EXTRN문을 올바르게 위치시키는 예(소형 모델에서) --------------------------------------------------------------------- _TEXT SEGMENT BYTE PUBLIC 'CODE' EXTRN _memset:NEAR EXTRN _nearmemset:NEAR _TEXT ENDS _DATA SEGMENT WORD PUBLIC 'DATA' EXTRN _i:WORD EXTRN _s:WORD EXTRN _fp:DWORD _DATA ENDS _BSS SEGMENT WORD PUBLIC 'BSS' EXTRN _array:WORD:10 EXTRN _c:WORD EXTRN _nearptr:WORD --- 명시적으로 near/far 수식자가 지정되어 EXTRN _farptr:DWORD --- 있으므로 DATAPTR를 쓰면 안 된다. _BSS ENDS _TEXT SEGMENT BYTE PUBLIC 'CODE' ASSUME cs:_TEXT, ds:_DATA ...... END --------------------------------------------------------------------- 3.4 원거리 외부명칭의 선언 위치 소형 모델에서만 작업을 할 것이라면 EXTRN문에 관한 한 더 이상 문제 될 건 없다. 하지만 다른 메모리 모델이라면 어떨까? 그 때의 문제는 바 로 _TEXT, _DATA, _BSS 등의 공통적인 세그먼트에 존재하지 않는 명칭의 선언을 과연 "어디다가 위치시키냐" 하는 것이다. 여기서 잠시 세 가지 새 로운 용어에 대한 정의를 내리겠다. 먼저 해당 모듈이 아닌 다른 모듈에 존재하는 명칭을 이름하여 "원거 리 외부명칭(far external)"이라고 한다. 또한 해당 모듈의 세그먼트를 " 근거리 세그먼트(near segment)", 다른 모듈의 서로 다른 세그먼트를 "원 거리 세그먼트(far segment)"라고 한다. 물론 이 용어 설명은 대형 코드/데이터 모델에서만 해당한다. 왜냐 하 면 소형 코드/데이터 모델에서는 서로 다른 모듈이라 할지라도 세그먼트가 실질적으로 _TEXT, _DATA, _BSS 등의 "근거리 세그먼트"밖에 없기 때문이 다. 따라서 그 경우에는 원거리 세그먼트가 존재하지 않는다고 볼 수 있 다. +---------------------------------------------------------+ | 근거리 세그먼트는 해당 모듈 내에 존재하는 세그먼트이다. | +---------------------------------------------------------+ | 원거리 세그먼트는 해당 모듈 내에 존재하지 않고 | | 또한 "그 명칭이 서로 다른" 세그먼트이다. | | (원거리 세그먼트는 원칙적으로 대형 코드/데이터 | | 모델에서만 존재함) | +---------------------------------------------------------+ | 원거리 외부명칭은 원거리 세그먼트에 존재하는 명칭이다. | +---------------------------------------------------------+ 예를 들어 앞 절에서 언급한 farmemset이라는 원거리 함수가 dummy.c 모듈의 DUMMY_TEXT라는 세그먼트에 존재한다고 치자. 대형 코드 모델에서 는 모듈명에 _TEXT가 덧붙은 명칭이 코드 세그먼트명으로 규정된다는 것은 옛날에 설명했다. void far farmemset(char far *dest, int value, long n); 이 때 거기에 존재하는 (원거리) 함수를 mymodule.asm이라는 어셈블리 모듈에서 참조하려면 과연 해당 EXTRN문을 어디다가 두어야 할까? 만에 하나 그 선언을 아래와 같이 어셈블리 모듈의 MYMODULE_TEXT 세그먼트 내 에 두면 한마디로 큰일난다는 것을 확실히 알아두기 바란다. 예를 들어 <예제 3>과 같이 하면, 어셈블러가 _farmemset의 옵셋을 DU MMY_TEXT 세그먼트의 선두로부터 계산하지 않고 MYMODULE_TEXT 세그먼트의 선두로부터 계산해 버린다. 그렇게 되면 당연히 프로그램이 제대로 돌아갈 리가 없다. 실행시에 프로그램이 폭주할 수도 있고, 64K바이트 이상의 덩 치 큰 프로그램에서는 링크시에 Fixup overflow라는 매우 곤혹스러운 에러 를 발생시키는 수도 있다. (실제로 필자가 당해 봤음. 며칠 밤낮을 끙끙대 고 헤맨 뒤에 우연히 틀린 위치에다가 선언한 것을 발견하고 허탈...) <예제 3> 원거리 명칭을 틀린 위치에서 선언한 예 --------------------------------------------------------------------- ; File MYMODULE.ASM(대형 코드 모델에서) MYMODULE_TEXT SEGMENT BYTE PUBLIC 'CODE' ASSUME ...... EXTRN _farmemset:FAR --- 원거리 세그먼트인 DUMMY_TEXT 내의 명칭을 MYMODULE_TEXT 내에서 선언하고 있다. ...... MYMODULE_TEXT ENDS --------------------------------------------------------------------- 그렇다면 쉽게 생각하기에는 DUMMY_TEXT라는 세그먼트를 어셈블리 모 듈 내에 마련해 두고 거기다가 EXTRN문을 두면 되지 않겠느냐고 할 수 있 다. 실제로 그리 해도 되긴 된다. <예제 4> 원거리 명칭을 선언한 예 1(바람직하지 못한 방법) --------------------------------------------------------------------- ; File MYMODULE.ASM(대형 모델에서) +---------------- dummy 모듈에 있는 코드 세그먼트 DUMMY_TEXT SEGMENT BYTE PUBLIC 'CODE' EXTRN _farmemset:FAR DUMMY_TEXT ENDS +----------------- mymodule 모듈의 원래 코드 세그먼트 | MYMODULE_TEXT SEGMENT BYTE PUBLIC 'CODE' ...... --- 이 모듈의 코드 세그먼트부 MYMODULE_TEXT ENDS ...... --- 그 밖의 ISD 또는 USID 세그먼트부(선택적) --------------------------------------------------------------------- 이 방법은 세 가지 정도의 문제점을 가지고 있다. 첫째는 한 모듈 내 에 두 개 이상의 코드 세그먼트 선언이 포함되어 있으므로 터보 C의 메모 리 모델 구조를 완전하게 따르지 못한다는 점이다. 두번째 문제는 바로 "너무 번거롭다"는 점이다. 즉 선언해야 할 원거 리 명칭이 여러 곳의 원거리 세그먼트에 분산되어 있다면 그 원거리 세그 먼트들을 일일이 마련하여야 한다는 것이다. 즉 10곳의 원거리 세그먼트에 있는 10개의 원거리 명칭을 참조하려면 10개의 세그먼트 선언이 추가로 필 요해진다. 이는 정말로 대단히 귀찮은 일이 아닐 수 없다. 마지막으로 이 방법으로는 어셈블러가 세그먼트 배치와 관련하여 제공 하는 .CODE, .DATA 등의 각종 편리한 지시자를 써서 구현할 수 없다는 단 점이 있다. 그렇다면 가장 간편한 방법이 무엇이냐 하면 바로 "모든 세그먼트의 외부에 원거리 명칭의 선언을 두는 것"이다. 이렇게 하면 어셈블러는 그 명칭의 세그먼트 및 옵셋을 계산할 수 없으므로 그 계산을 링커쪽으로 미 룬다. 그러면 링커가 올바른 세그먼트:옵셋 조합을 계산해 준다. +---------------------------------------------------+ | 원거리 명칭의 선언은 모든 세그먼트의 외부에 둔다. | | 즉, 어떠한 세그먼트에도 속하지 않도록 한다. | +---------------------------------------------------+ <예제 5> 원거리 명칭을 선언한 예 2(바람직한 방법) --------------------------------------------------------------------- ; File MYMODULE.ASM(대형 모델에서) EXTRN _farmemset:FAR --- 어떠한 세그먼트에도 속해 있지 않다! MYMODULE_TEXT SEGMENT BYTE PUBLIC 'CODE' ...... --- 이 모듈의 코드 세그먼트부 MYMODULE_TEXT ENDS ...... --- 그 밖의 ISD 또는 USID 세그먼트부(선택적) --------------------------------------------------------------------- #55 임인건 (turbo28 ) [강좌] C깊은곳5-2: 어셈블리 코드 접속 II 05/06 00:21 408 line --------------------------------------------------------------------- 4 C 모듈에서 어셈블리 함수의 호출 --------------------------------------------------------------------- 다음으로, C는 매개변수를 스택을 통하여 전달한다. 지난 회에서 설명 했다시피 함수를 호출하기 전에 터보 C는 먼저 가장 오른쪽(마지막) 매개 변수부터 왼쪽의 순으로 차례차례 매개변수를 스택상에 대피(push)시킨다. 예컨데 터보 C쪽에서의 함수 호출이 아래와 같다면, int test(int a, int b, int c); --- 함수 원형 ...... result = test(i, j, 1); ...... 소형 코드 모델에서 터보 C는 다음과 같이 컴파일한다. mov ax,1 push ax push WORD PTR DGROUP:_j push WORD PTR DGROUP:_i call NEAR PTR _test add sp,6 여기서 가장 오른쪽 (실)매개변수 1부터 먼저 스택에 대피됨을 볼 수 있을 것이다. 또한 주목할 사항은 피호출 함수인 test의 수행이 종료된 후 복귀할 때, 스택 포인터 레지스터 SP의 복구를 test가 행하지 않고 호출한 쪽에서 행한다는 점이다. 위에서 보다시피 SP의 복구를 행하는 명령인 add sp,6이 호출한 쪽에 놓여 있다. 참고로 SP에다가 6을 더하는 이유는 스택 에 대피된 매개변수의 총 바이트 크기가 3 x 2 == 6 바이트이기 때문이다. 물론 pop 명령을 3번 써도 되지만, 이 경우에는 add 명령을 쓰는 게 처리 속도가 약간 빠르다. +----------------------------------------------------------+ | SP의 복구는 피호출 함수가 아니라 호출 함수쪽에서 행한다. | +----------------------------------------------------------+ 어쨌든 SP의 복구를 호출 함수쪽에서 담당하기 때문에 피호출 함수는 호출 함수가 과연 몇 개의 실매개변수를 스택에 대피시켰는지 "원칙적으로 는" 전혀 알 방도가 없다. 이 말을 역으로 하면 매개변수의 개수가 가변인 함수도 만들 수 있다는 얘기가 된다. 대표적인 예가 바로 printf 함수이 다. 참고로 printf 함수는 서식문자열(format string) 내의 서식의 개수에 의해 매개변수의 개수를 판정하게 된다. 다음으로 넘어가기 전에 잠깐 용어 두 개만 더 정의하자. 다름이 아니 라, "C 함수"란 C 모듈쪽에서 정의된 함수를 뜻하고, "어셈블리 함수"란 어셈블리 모듈쪽에서 정의된 함수를 뜻한다는 것이다. --------------------------------------------------------------------- 5 진입 코드와 탈출 코드 --------------------------------------------------------------------- C에서 함수는 "BP를 통해서 실매개변수를 참조"하도록 규칙이 정해져 있다. 즉 BP에다가 특정한 옵셋을 더한 위치의 스택을 참조하면 된다. +------------------------------------+ | 실매개변수는 BP를 통해서 참조한다. | +------------------------------------+ 여기서 주의할 점이 하나 있다. C는 모든 함수 호출을 전후하여 BP값 이 유지된다고 가정한다. 그러므로 피호출 함수는 그 선두에서 반드시 BP 를 대피시켜야만 한다. 그런 다음 BP에 SP값을 복사하여 실매개변수의 참 조에 이용한다. 이를 처리해 주는 간단한 코드를 이름하여 "진입 코드(ent ry code)"라고 부른다. 마찬가지로 피호출 함수가 수행을 종료하고 복귀할 때에는 반드시 BP 를 호출되기 전의 원래의 값으로 복구시켜 놓아야만 한다. 즉 pop bp 명령 을 ret 명령 직전에 두어야 한다. 이 두 명령을 이름하여 "탈출 코드(exit code)"라고 부른다. 이상의 규칙은 피호출 함수 내에서 자동변수를 전혀 쓰지 않을 때의 얘기이며, 이를 일반적으로 나타내면 <그림 1>과 같다. <그림 1> 피호출 함수 내에서 자동변수를 전혀 쓰지 않을 때 진입 코드와 탈출 코드의 일반적인 예 ------------------------------------------------------------ SI와 DI를 전혀 쓰지 않을 때 SI와 DI를 사용할 때 ------------------------------------------------------------ ...... PROC ...... ...... PROC ...... push bp push bp mov bp,sp mov bp,sp push si push di ...... ...... pop di pop si pop bp pop bp ret ret ...... ENDP ...... ENDP ------------------------------------------------------------ <그림 1>에서 SI, DI를 사용할 때 두 레지스터를 대피시켜야 하는 이 유는 C가 모든 함수 호출 전후에 SI와 DI값이 유지된다고 가정하기 때문이 다. SI와 DI는 터보 C에서 레지스터 변수로 사용된다. 예를 들어 test 함 수는 <예제 6>과 같을 수 있다. 보면 금방 알겠지만 (i + j - 1)의 수식을 계산해서 그 결과를 ax에 담아서 반환하는 단순한 함수이다. <예제 6> 소형 모델에서 test 함수의 예 ---------------------------------------------------- _TEXT SEGMENT BYTE PUBLIC 'CODE' _test PROC NEAR +-----------------------------------------+ 진입 | push bp --- (1) | 코드 | mov bp,sp --- SP를 BP에 복사한다. | +-----------------------------------------+ mov ax,[bp+4] --- 실매개변수 i의 값 add ax,[bp+6] --- 실매개변수 j의 값 sub ax,[bp+8] --- 실매개변수 1 +-----------------------------------------+ 탈출 | pop bp | 코드 | ret --- 반환값은 AX에 담아서 되돌린다. | +-----------------------------------------+ _test ENDP END ---------------------------------------------------- <예제 6>에서 test 함수 본체의 선두와 끝에 각각 합당한 진입 코드와 탈출 코드가 놓여 있는 것을 볼 수 있을 것이다. 여기서 test 함수는 SI와 DI를 전혀 쓰지 않기 때문에 그 두 레지스터를 스택에 대피시키지 않고 있 다. --------------------------------------------------------------------- 6 실매개변수의 참조 --------------------------------------------------------------------- 6.1 소형 코드 모델에서 매개변수의 참조 계속해서 <예제 6>의 test 함수가 매개변수를 참조하는 방법에 대하여 알아보자. 우선 알아야 할 사항은 왜 [bp+4]가 실매개변수 i가 되는가 하 는 것이다. 그것은 다음 <그림 2>의 스택 상황을 보면 알 수 있다. 상세히 설명하 자면, 우선 bp+0의 2바이트 영역에는 <예제 6> (1) 위치의 push bp 명령에 의해 호출 함수(calling function)쪽에서 쓰던BP값이 대피되어 있다. 다 음 bp+2의 2바이트 영역에는 나중에 ret 명령에 의해 호출 함수로 되돌아 갈 때의 복귀 번지(return address)가 저장되어 있다. 위의 <예제 6>에서 는 소형 코드 모델이기 때문에 복귀 번지가 2바이트의 크기를 가진다. <그림 2> test가 호출된 직후의 스택 상황 ---------------------------------------------------- | | 번지 참조 하위번지 +----------+ | | BP값대피 | -- BP | +----------+ | | 복귀번지 | -- BP+2 | +----------+ | | i의 값 | -- BP+4 [BP+4] | +----------+ | | j의 값 | -- BP+6 [BP+6] | +----------+ | | 1 | -- BP+8 [BP+8] 상위번지 +----------+ | | ---------------------------------------------------- 이상의 스택 구조로 인해 첫번째 실매개변수 i의 값은 bp+4 위치의 스 택 영역에서 참조할 수 있다. i의 값은 첫번째 실매개변수이기 때문에 맨 마지막으로 스택에 대피되며, 그래서 BP에 상대적으로 가장 가까운 곳에 i 의 값이 놓인다는 것은 누차 언급했다. 6.2 대형 코드 모델에서 매개변수의 참조 소형 코드 모델에서는 BP+4에 첫번째(맨 왼쪽) 실매개변수값이 놓인 다. 그렇다면 대형 코드 모델에서도 BP+4에 놓일까? 전혀 그렇지 않다. 주지하다시피 대형 코드 모델에서는 원거리 호출을 행하기 때문에 "복귀 번지는 4바이트의 크기"를 가지게 된다. 그래서 첫번째 매개변수의 위치는 BP+4가 아니라 BP+6이 되어야 한다. 즉, 대형 코드 모델에서는 소형 코드 모델에서보다 2만큼씩 추가적인 옵셋의 증가가 요구된다. 만약 모든 매개변수의 크기가 2바이트로 일정하다는 가정을 하고 일반 적으로 도표화하면 다음 <표 1>과 같다. 물론 그 크기가 일정치 않으면 <표 1>은 성립되지 않는다. <표 1> 매개변수의 참조 ---------------------------------------------- 매개변수 소형 코드 모델 대형 코드 모델 ---------------------------------------------- 1번째 [BP+4] [BP+6] 2번째 [BP+6] [BP+8] ... n번째 [BP+2+n*2] [BP+4+n*2] ---------------------------------------------- * 단, 모든 매개변수가 2바이트의 크기를 가질 때에만 성립한다. --------------------------------------------------------------------- 7 자동변수의 정의 및 참조 --------------------------------------------------------------------- 어셈블리 함수 내에서 자동변수를 쓰려면 일단 자동변수를 위한 스택 영역을 확보해 두어야 한다. 그러기 위해 보통 sub sp,n이라는 명령을 쓴 다. 여기서 n은 사용할 자동변수의 총 바이트 크기로서 상수이다. 이렇게 자동변수의 영역을 확보하는 것이 곧 자동변수의 "정의"가 된다. 일단 SP값을 감소시킴으로써 스택 영역을 확보한 뒤에 자동변수의 참 조는 BP를 통해 이루어진다. SP를 이용하면 안 되는 이유는, 일반적으로 함수 내에 흔히 등장하는 push/pop 명령에 의해 SP의 값이 수시로 변하기 때문이다. 그래서 고정적인 BP를 써서 참조하는 것이 원칙이다. 자동변수를 쓰는 경우 진입코드와 탈출코드는 각각 스택 영역을 확보 하고 복귀시 SP값을 환원시키기 위해 <그림 3>과 같이 수정되어야 한다. <그림 3> 피호출 함수 내에서 자동변수를 사용할 때 진입 코드와 탈출 코드의 일반적인 예 ----------------------------------------------------- SI와 DI를 전혀 쓰지 않을 때 SI와 DI를 사용할 때 ----------------------------------------------------- ...... PROC ...... ...... PROC ...... push bp push bp mov bp,sp mov bp,sp sub sp,n sub sp,n push si push di ...... ...... pop di pop si mov sp,bp mov sp,bp pop bp pop bp ret ret ...... ENDP ...... ENDP ----------------------------------------------------- * n은 자동변수의 총 바이트 크기이다. 그리고 첫번째 자동변수의위치는 BP-2가 되며, 만약 그 자동변수가 2 바이트 크기라면 [BP-2]로 참조할 수 있다. 전과 같이 모든 자동변수의 크 기가 2바이트로 일정하다면 <표 2>의 공식들이 성립된다. 여기서 메모리 모델에 따라 BP의 옵셋이 차이가 나지는 않는다는 점에 유의하기 바란다. <표 2> 자동변수의 참조 -------------------------- 자동변수 참조 -------------------------- 1번째 [BP-2] 2번째 [BP-4] ... n번째 [BP-n*2] -------------------------- * 단, 모든 자동변수가 2바이트의 크기를 가질 때에만 성립한다. --------------------------------------------------------------------- 8 어셈블리 함수에서 C 함수의 호출 --------------------------------------------------------------------- 어셈블리 함수에서 C 함수를 호출하는 방법은 앞에서 C 함수에서 어셈 블리 함수를 호출하는 방법과 똑같다. 앞에서는 간단한 예만 들었기 때문 에 여기서는 자세히 설명하고자 한다. 원칙은 다음과 같다. +-- 호출 직전 -------------------------------------------+ | 마지막(맨 오른쪽) 실매개변수를 제일 처음에 대피시킨다. | | 첫번째(맨 왼쪽) 실매개변수를 제일 마지막에 대피시킨다. | +--------------------------------------------------------+ +-- 호출 직후 -----------------------------------------------+ | SP를 원래대로 복구시킨다. | | 즉, SP에 대피시켰던 실매개변수의 총 바이트 크기를 더하거나 | | 해당하는 만큼의 pop 명령을 두면 된다. | +------------------------------------------------------------+ 원칙은 이뿐이다. 따라서 실매개변수를 스택에 대피시키는 방법은 편 리한 대로 하면 된다. 다만 한 가지 주의할 점이 있다. 즉, 스택상으로의 대피는 항상 2바이 트의 워드 단위로 이루어지기 때문에, 만약 1바이트짜리 실매개변수라 할 지라도 대피는 2바이트 단위로 해야한다는 점이다. 따라서 1바이트짜리 실 매개변수는 반드시 2바이트의 크기로 부호확장(sign extension)시킨 후에 대피시켜야 한다. +--------------------------------------------+ | 1바이트 크기의실매개변수는 2바이트 크기로 | | 부호확장시킨 후에 스택에 대피시켜야 한다. | +--------------------------------------------+ 부호확장 방법은 다음과 같다. -------------------------------------------------------------- * 부호있는 char형이라면, 음수인 경우 상위 바이트를 0xff, 0 또는 양수인 경우 0x00으로 설정한다. * 부호없는 unsigned char형이라면, 상위 바이트는 무조건 0x00. -------------------------------------------------------------- 또한어셈블리 모듈에서는 극히 드문 경우이겠지만, 4바이트 크기의 f loat형의 변수는 8바이트 크기의 double형으로 변환한 후에 대피시켜야 한 다는 점도 참고하기 바란다. --------------------------------------------------------------------- 9 EQU 지시자를 응용한 매개변수/자동변수의 참조 --------------------------------------------------------------------- 매개변수나 자동변수를 참조하기 위해 번번히 BP에 옵셋을 더한 수식 을 써야 하는 것은 지극히 번거롭기 짝이 없다. 하지만 간단한 고전적인 테크닉을 쓰면 그 번거로움을 다소나마 줄일 수 있다. 그것은 EQU 지사자 를 이용하는 방법이다(이하 EQU문으로 약칭). 예컨데 test 함수의 경우 [BP+4], [BP+6], [BP+8]을 직접 기술하는 대 신에 <예제 7>과 같이 EQU문으로 a, b, c를 정의하여 사용하면 된다. <예제 7> 소형 모델에서 test 함수의 예 2 ---------------------------------------------------- a EQU [bp+4] b EQU [bp+6] c EQU [bp+8] _TEXT SEGMENT BYTE PUBLIC 'CODE' _test PROC NEAR +----------------------------------------+ 진입 | push bp --- (1) | 코드 | mov bp,sp --- SP를 BP에 복사한다. | +----------------------------------------+ mov ax,a add ax,b sub ax,c +-----------------------------------------+ 탈출 | pop bp | 코드 | ret --- 반환값은 AX에 담아서 되돌린다. | +-----------------------------------------+ _test ENDP END ---------------------------------------------------- 그런데 어떻게 보면 EQU문으로 매개변수나 자동변수의 위치를 일일이 정의하여 사용하는 것조차 번거로울 때가 많다. 특히 매개변수를 참조할 때에는, 메모리 모델에 따라 BP에 대한 옵셋이 차이가 나기 때문에 더더욱 번거롭다. 그래서 터보 어셈블러 등에서는 매개변수 및 자동변수의 참조를 위해 매우 유용한 ARG 및 LOCAL 지시자를 제공하기는 하는데, 지면상 다음 달로 설명을 미루겠다. --------------------------------------------------------------------- 10 어셈블리 모듈의 어셈블 방법과 최종적인 링크 방법 --------------------------------------------------------------------- 어셈블리 모듈을 어셈블하는 방법에는 두 가지가 있다. 하나는 당연히 어셈블러를 직접 실행시켜서 써서 어셈블하는 것이고, 다른 하나는 터보 C 명령행 버전인 tcc.exe를 써서 간접적으로 어셈블러를 실행시켜 어셈블하 는 방법이다. 우선 첫번째 방법은 다음과 같다. 이 때 물론 tasm.exe나 masm.exe는 도스 PATH 명령에 의해 지정된 검색 경로(search path) 상에 존재해야 한 다. 그리고 /mx나 /MX 옵션을 주는 이유는 외부명칭에서 대소문자가 구별 되도록(case-sensitive) 하기 위함이다. 이 옵션을 빠뜨리면 나중에 링크 할 때 Undefined symbol 에러를 무더기로 양산하게 되니 주의하기 바란다. [1] 터보 어셈블러를 쓸 때 → /mx 옵션을 지정 C:\TURBOC\WORK>tasm /mx filename [2] 매크로 어셈블러를 쓸 때 → /MX 옵션을 지정 C:\TURBOC\WORK>masm /MX filename 이 방법은 어셈블리 모듈만을 어셈블할 경우에 유용하다. 반면에 두번 째 방법은 어셈블리 모듈뿐만아니라 C 모듈까지 한꺼번에 컴파일/어셈블 하고자 할 때 매우 유용한다. 즉, tcc.exe를 통해 간접적으로 어셈블하면 tcc.exe가 내정된/지정된 메모리 모델에 따라 적절한 옵션으로 링커 tlin k.exe까지 알아서 실행시켜 주므로 대단히 편리하다. 특히 tlink.exe를 직 접 실행시킬 때와 달리 기동 모듈(startup module)이나 터보 C 표준 라이 브러리 화일들을 명시적으로 지정할 필요가 없어서 대단히 편리하다. 예를 들어 전체 프로그램이 메인 C 모듈 main.c와 어셈블리 모듈 mymo dule.asm의 두 화일로 구성되어 있다면 아래와 같이 tcc.exe를 실행시키면 된다. 물론 아래의 예에서는 소형 모델로 컴파일된다. 만약 다른 모델, 예 컨데 대형 모델로 컴파일하고 싶다면 -ml 옵션을 주면 된다. C:\TURBOC\WORK>tcc main mymodule.asm 위에서 보다시피 mymodule 모듈을 그저 C 모듈 지정하듯이 하면 그만 이다. 딱 한 가지 주의할 점으로, 확장자 .ASM을 빠뜨리지 않고 지정하기 만 하면 만사 OK! 이렇게 해주면 tcc.exe는 main 모듈을 컴파일하고 곧 이 어 tasm.exe를 실행시켜 mymodule.asm을 어셈블한 뒤 tlink.exe를 실행시 켜 링크까지 일괄적으로 처리해 준다. 만약 mymodule.asm을 어셈블만 시키고 싶다면 아래와 같이 -c 옵션을 주어서 링크 작업을 금지시키면 된다. main 모듈을 컴파일만 시키고 싶을 때도 마찬가지로 -c 옵션을 주면 된다. C:\TURBOC\WORK>tcc -c mymodule.asm 한편 링크 작업만 단독으로 처리해야할 필요를 느낄 때도 있을 것이 다. 그런데 링커를 직접 실행시키는 것은 정말로 번거롭기 짝이 없다. 왜 냐 하면 기동 모듈은 물론 터보 C 라이브러리 화일까지 완전하게 지정해 주어야 하기 때문이다. 따라서 링커를 직접 실행시키는 방법은 실로 무식 한 방법이 아닐 수 없다. 보다 현명한 방법은 tcc.exe를 통해 간접적으로 링크하는 방법이다. 즉, tcc.exe에 프로그램을 구성하는 모든 모듈들을 지정할 때 목적 화 일명으로 지정하면, 다시 말해서 확장자 .OBJ까지 빠뜨리지 않고 지정하 면, tcc.exe는 컴파일/어셈블은 전혀 행하지 않고 즉시 tlink.exe를 불러 서 링크 작업을 수행하도록 한다. 이 때 tcc.exe는 메모리 모델에 따라 적 절한 옵션, 기동 모듈 및 터보 C 라이브러리 화일을 지정하여 터보 링커t link.exe를 부르기 때문에 프로그래머 입장에서는 상당한 번거로움을 덜 수 있다. C:\TURBOC\WORK>tcc main.obj mymodule.obj 위에서 만약 터보 C 표준 라이브러리가 아닌 별도의 라이브러리가 쓰 인다면 끝부분에 .LIB 확장자를 빠뜨리지 않고 지정해 주면 된다. --------------------------------------------------------------------- 11 다음에는 --------------------------------------------------------------------- 다음 달에는 계속해서 터보 어셈블러가 터보 C를 지원하기 위해 제공 하는 매우 편리한 기능인 "단순화 세그먼트 지시자(simplified segment di rective)" DOSSEG, .MODEL, .CODE, .DATA 등등과 더불어 매개변수 및 자동 변수를 정의/참조하는데 상당한 유용성을 가져다 주는 ARG 및 LOCAL 지시 자에 대하여 상세히 알아보겠다. 아마 이 지시자들에 익숙해지면 다시는 번거로운 SEGMENT, GROUP 등의 지시자를 쓰지 않게 될 것이다.