>>> 터보 C의 깊은 곳 <<< 제4회 어셈블리 코드 접속 Assembly Code Interface 글/임인건 (서울대 기계공학과4) --------------------------------------------------------------------- 1 본문에 앞서 --------------------------------------------------------------------- 이제까지 독자 여러분과 함께 크게 세 가지를 알아보았다. 하나는 터 보 C가 제공하는 각종 메모리 모델의 구조이고, 다른 하나는 함수 호출 방 식이며, 나머지 하나는 C 호출 관행(C 방식 매개변수 전달 방식)이었다. 그리고 그 C 호출 관행이 실제로 어셈블리 수준에서 어떻게 구현되는가에 대해 감을 잡기 위한 예도 접해 보았다. 이번 달에는 계속해서 어셈블리 코드와 C 루틴과의 접속(interface)을 위해 어셈블리 모듈 쪽에서 과연 어떠한 조치가 취해져야 하는가에 관한 갖가지 규칙들을 상세히 알아보도록 하겠다. 이번 연재의 가장 핵심되는 부분이 본격적으로 시작되므로 주의 깊게 읽어 나갔으면 한다. 저번 달까 지는 서론에 불과하다. 참고로 이번 글에서는 독자가 8086계열 어셈블리에 대하여 충분한 사 전 지식을 가지고 있다는 가정하에 진행할 것이다. 즉 각종 8086 명령어들 은 물론이고 DW, DD, PUBLIC, EXTRN, SEGMENT, GROUP 등 어셈블러의 주요 한 각종 지시자(directive)의 사용법에 관련된 충분한 지식들도 요한다. 만약 이에 대한 지식이 불충분하다면 해당 어셈블리 관련 서적들을 참고하 기 바란다. --------------------------------------------------------------------- 2 어셈블리 코드 접속 개요 --------------------------------------------------------------------- 어셈블리 루틴은 C에서 볼 때 전체 프로그램의 일부분으로서 링크될 하나의 독립된 모듈로 간주된다. 그래서 어셈블리 루틴은 어셈블리 모듈이 라고도 불리며, 그 어셈블리 모듈이 링커에 의해 적법한 C 모듈로 인식되 기 위한 갖가지 관행(규칙)들이 지켜져야 하는데, 그것은 대략 다음과 같 다. [1] 어셈블리 모듈은 타 모듈과의 접속을 위해 링커가 필요로 하는 모든 정보를 완전하게 제공해야 한다. 예를 들어 각종 "외부명칭(external identifier)에 관련된 정보" 등을 세세하고 틀림없이 기술해 줘야 한 다. [2] 정해진 메모리 모델의 구조를 유지하기 위한 "세그먼트 배치 규칙"이 철저하고 일관되게 지켜져야 한다. 즉 하나의 실행 화일로서 링크될 모든 모듈은 동일한 모델 구조를 가져야 한다. 물론 메모리 모델을 혼 용할 수도 있지만 그것은 대단히 위험한 작업이 된다. 우선은 2번 사항에 해당하는 설명부터 해 나가겠는데, 그 전에 한 가 지 분명히 해둘 일이 있다. 그것은 정적 데이터의 두 가지 큰 구분에 대 한 것이다. --------------------------------------------------------------------- 3 초기화된 정적 데이터와 비초기화된 정적 데이터 --------------------------------------------------------------------- 전에도 언급했지만 다시 한번 자세히 설명하자면, "정적 데이터(stati c data)"란 각종 외부변수, 정적변수 및 문자열 상수 세 가지들을 총칭하 는 말이다. 다만 문자열 상수는 터보 C 내부적으로 볼 때 함수 내에서 정 의되는 내부정적변수(internal static variable)와 동등하게 취급되기 때 문에(<리스트 8> 참고), 이후의 설명에서 문자열 상수에 관한 사항은 정적 변수의 관점에서 유추하여 생각해 보면 틀림없을 것이다. 실제로 어셈블리 수준에서는 문자열 상수와 정적변수가 문법적으로 구별되지 않는다. 한편 이 정적 데이터는 예외 없이 데이타 세그먼트의 선두, 즉 옵셋으 로 0x0000 번지 이후에 놓이도록 되어 있다. 자세한 것은 6월 달에 게재한 각 메모리 모델의 지도를 참고하기 바란다. 다시 본론으로 되돌아 가서, 정적 데이타는 다시 그 초기화 여부에 따 라 "초기화된 정적 데이타(initialized static data)"와 "비초기화된 정적 데이타(uninitialized static data)"로 나뉜다. 편의상 이제부터 전자를 I SD, 후자를 UISD라고 약칭하겠다. 여기서 초기화 여부는 외부변수 혹은 정적변수를 정의할 때(선언할 때 가 아님!) 그 초기치(initializer)를 명시적으로 지정했느냐에 달려 있다. 예를 들어 아래의 외부변수 정의에서 볼 때 initvar는 ISD에 속하고 unini tvar는 UISD에 속한다. int initvar = 10; int uninitvar; 이런 구분이 생겨난 근본적인 이유는 한마디로 컴파일된 목적 화일 및 실행 화일의 크기를 대폭 줄이기 위한 것이다. 다들 알다시피 UISD는 프로 그램 실행 직후에 0 또는 0에 상당하는 값(이를 테면 널 문자 '\0')으로 초기화된다. 여기서 주목할 것은 "프로그램 실행 직후"라는 대목이다. 이 대목에서 볼 때 실행 화일 자체는 그 초기치(즉 0)를 포함하지 않고 있음 을 직감할 수 있을 것이다. 구체적으로 말해서 UISD들은 실행 화일 내에 그 공간이 마련되는 것이 아니라, 다만 실행 직후에 기동 코드(startup code)에 의해서 그 영역이 할당되고 곧이어 0으로 초기화될 따름이다. 그래서 결과적으로 실행 화일 의 크기를 UISD가 차지하는 영역만큼 감소시키는 효과를 가져온다. --------------------------------------------------------------------- 4 어셈블리 모듈의 일반적인 작성 양식 --------------------------------------------------------------------- <리스트 1>에 어셈블리 모듈의 일반적인 작성 양식을 보였다. 주목해 서 볼 것은 SEGMENT 및 GROUP 지시자에 관련된 사항이다. 이들은 어셈블리 모듈이 일관되게 지켜야 할 세그먼트 배치 규칙의 모든 것을 보여 준다. <리스트 1> 어셈블리 모듈의 일반적인 양식 --------------------------------------------------------------------- ; ; 각종 주석문(일반적으로 프로그램 제목) ; +--- 코드 세그먼트명 SEGMENT BYTE PUBLIC 'CODE' ASSUME cs:, ds: << 코드 세그먼트부 >> ← 보통(약간 큰) 고딕체 여기다 코드(각종 어셈블리 명령들)를 둔다 ← 작은 글자체 ENDS +------ 데이타 그룹명 --- _BSS 세그먼트를 GROUP _DATA, _BSS 생략했을 경우 삭제한다. +------ 초기화된 데이타 세그먼트명 SEGMENT WORD PUBLIC 'DATA' << 초기화된 데이타 세그먼트부 >> 여기다 ISD의 정의를 둔다. ENDS +------ 비초기화된 데이타 세그먼트명 _BSS SEGMENT WORD PUBLIC 'BSS' << 비초기화된 데이타 세그먼트부 >> 여기다 UISD의 정의를 둔다. 이 _BSS 세그먼트는 선택적이다. 즉 생략 가능하다. _BSS ENDS END --------------------------------------------------------------------- <리스트 1>에서 , 는 각 메모리 모델에 따라서 <표 1>에 서 미리 정해진 (논리) 세그먼트명으로 치환되어야 한다. 마찬가지로 도 미리 정해진 그룹명으로 치환되어져야 한다. 이 세그먼트명 및 그룹 명은 프로그램 전체에 걸쳐 일관되게 지켜져야 하며, 그렇지 않을 경우 링 크 및 실행시 예기치 못한 에러가 발생한다. 물론 익숙해지면 별 것도 아 니겠지만 처음 배울 때에는 특히 유념해야 할 것이다. <리스트 1>에 대해 부연해야 할 사항이 두 가지 있다. 그것은 첫째, U ISD가 위치할 _BSS 세그먼트는 선택적(optional)이라는 것이다. 다시 말해 서 UISD가 어셈블리 모듈 내에 하나도 존재하지 않는다면, 즉 모든 정적 데이타에 초기치가 지정되어 있다면, _BSS 세그먼트를 생략할 수도 있다. 물론 _BSS를 생략할 경우에 GROUP 의사 명령문에서 _BSS를 삭제해야 한다. 그리고 거대 모델에서는 데이타 세그먼트가 각 모듈마다 독립적으로 존재한다는 특성 때문에 다른 모델과 달리 유일하게 UISD를 인정하지 않는 다. 즉 C 문법상으로는 초기치를 지정하지 않은 UISD라 할지라도 내부적으 로는 0이라는 초기치가 지정된 ISD로 간주된다. 따라서 거대 모델에서는 _ BSS 세그먼트를 절대로 두어서는 안 되며 모두 해당 모듈의 ISD 영역에 쓸 어 담아야 한다. 참고로 0이라는(또는 0에 상당하는) 초기치가 명시적으로 지정된 변수 는, 비록 UISD가 0으로 초기화되기는 하지만, ISD로 간주된다는 점에 유의 하기 바란다. 어셈블리 모듈에서 UISD를 정의하는 방법은 DB, DW 등에 0의 초기치를 지정하는 게 아니라 ? 기호를 지정하여 초기치를 명시하지 않는 것이다. 비록 추후에 0으로 초기화되더라도 말이다. 실례는 <리스트 7>과 <리스트 8>를 비교하여 참고하기 바란다. --------------------------------------------------------------------- 5 세그먼트 배치 규칙 --------------------------------------------------------------------- 이제부터 설명할 내용은 지정된 메모리 모델에 따라 그 구조를 유지하 기 위한 세그먼트 배치 규칙들로서 반드시 철저하게 지켜져야 한다. 단 한 가지라도 빠뜨리거나 잘못 지정하면 링크 또는 실행시 예기치 못한 에러가 발생하거나 프로그램이 사전 경고(?) 없이 그냥 폭주해 버리므로 주의에 주의를 거듭하기를 당부한다. 참고로 터보 어셈블러에서는 터보 C 호환의 메모리 모델을 지정할 수 있기 때문에 세그먼트 배치를 위해 복잡하게 SEGMENT와 DGROUP 지시자를 쓸 필요가 없어서 대단히 편리하다. 하지만 일단 알아 두기는 해야 할 것 이다. 전자계산기 쓰면 된다고 해서 손으로 나눗셈하는 방법을 배우지 않 겠다면 이건 좀 곤란하지 않는가? 터보 어셈블러의 메모리 모델 지원 관 련 기능은 두세 달 후에 분위기가 무르익으면 자세히 설명하겠다. 미리 알 아보고 싶은 독자는 Turbo Assembler 1.0 User's Guide 312~315쪽을 참고 하기 바란다. 5.1 코드 세그먼트 +--------------------------------------+ | SEGMENT BYTE PUBLIC 'CODE' | | ASSUME cs:, ds: | +--------------------------------------+ [1] (논리) 코드 세그먼트명 는 메모리 모델에 따라 반드시 <표 1> 에 정해져 있는 명칭이어야 한다. [2] 정렬형식(alignment)은 BYTE형이다. [3] 조합형식(combine type)은 반드시PUBLIC이어야 한다. PUBLIC을 생략 하면 각 논리 세그먼트가 하나의 물리 세그먼트로 결합되지 못하기 때 문에 링크 및 실행시 에러가 나거나 프로그램이 폭주해 버린다. [4] 클래스명(class name)은 반드시 'CODE'이어야 한다. 만약 빠뜨리거나 다른 클래스명을 쓰면 각각의 (논리) 코드 세그먼트들을 연속되게 위 치시킬 수 없으므로 정해진 메모리 모델의 구조를 따를 수 없게 된다. [5] ASSUME문에서 코드 세그먼트 레지스터 CS는 를 세그먼트 베이스 로 취하고 데이타 세그먼트 레지스터 DS는 그룹 를 세그먼트 베 이스로 취해야 한다. 여분(extra) 세그먼트 레지스터 ES는 아무래도 상관없으나 일반적으로 를 세그먼트 베이스로 취한다. 유의할 사항은 <표 1>에도 나타냈지만 나 는 메모리 모델에 따라 서 항상 동일한 명칭일 수도 있고, 각 모듈마다 별도의 명칭이 될 수 도 있다는 점이다. 5.2 데이타 세그먼트 +------------------------------------+ | 그룹 선언 | | GROUP _DATA, _BSS | +------------------------------------+ | 초기화된 데이타 세그먼트의 선언 | | SEGMENT WORD PUBLIC 'DATA' | +------------------------------------+ | 비초기화된 데이타 세그먼트의 선언 | | _BSS SEGMENT WORD PUBLIC 'BSS' | +------------------------------------+ [1] (논리) 데이타 세그먼트명 는 메모리 모델에 따라 반드시 <표 1>에 정해져 있는 명칭이어야 한다. 예컨데 거대 모델이 아니라면 는 항상 _DATA이다. [2] 정렬형식(alignment)은 WORD형이다. [3] 조합형식(combine type)은 반드시 PUBLIC이어야 한다. PUBLIC을 생략 하면 각 논리 세그먼트가 하나의 물리 세그먼트로 결합되지 못하기 때 문에 링크시 에러가 나거나 실행시 전혀 엉뚱한 정적 데이타들을 참조 하게 된다. 그리고 이런 부류의 에러는 대단히 찾기 힘든 게 보통이 며, 복잡한 프로그램일수록 신의 가호가 있기 전에는 못 찾는다고 보 면 된다. [4] 클래스명(class name)은 반드시 'DATA' 및 'BSS'이어야 한다. 만약 빠 뜨리거나 다른 클래스명을 쓰면각 논리적인 코드 세그먼트들을 한 군 데로 모을 수 없으므로, 정해진 메모리 모델의 구조를 따를 수 없게 되어, 예기치 못하는 에러가 발생할 수 있다. [5] UISD가 하나도 존재하지 않는 경우 _BSS 세그먼트는 생략할 수 있다. 이 때 물론 그룹 선언에서도 역시 _BSS를 생략해 주어야 한다. [6] 초소형 모델에서의 그룹 선언은 예외로 다음과 같아야 한다. +------------------------------------+ | DGROUP GROUP _TEXT, _DATA, _BSS | +------------------------------------+ 즉, CS와 DS가 항상 일치되므로 _TEXT 세그먼트가 DGROUP에 포함되어 야 한다. [7] 거대 모델에서는 DGROUP이 전혀 쓰이지 않는다. 각 모듈에 속한 데이 터 세그먼트는 서로 독립적이기 때문이다. 5.3 스택 세그먼트 +--------------------------------+ | _STACK SEGMENT STACK 'STACK' | +--------------------------------+ [1] 스택 세그먼트에 대한 선언은 초소형 모델을 제외한 다른 메모리 모델 에서만 가능하다. [2] 스택 세그먼트에 대한 선언은 위와 같으나 일반적으로어셈블리 모듈 에 포함시킬 필요는 없다. 왜냐 하면 기동 코드 모듈에 이미 선언되어 있기 때문이다. <표 1> 메모리 모델에 따른 치환 규칙과 코드 및 데이타 포인터 변수의 정의 양식 -------------+----------------------+------------------------- 메모리 모델 | 치환 규칙 | 코드 및 데이타 | | 포인터 변수의 정의 -------------+----------------------+------------------------- 초소형 | = _TEXT | 코드 DW _TEXT:변수명 소형 | = _DATA | 데이타 DW DGROUP:변수명 | = DGROUP | -------------+----------------------+------------------------- 중소형 | = _TEXT | 코드 DW _TEXT:변수명 | = _DATA | 데이타 DW DGROUP:변수명 | = DGROUP | -------------+----------------------+------------------------- 중형 | = 모듈명_TEXT | 코드 DD 변수명 | = _DATA | 데이타 DW DGROUP:변수명 | = DGROUP | -------------+----------------------+------------------------- 대형 | = 모듈명_TEXT | 코드 DD 변수명 | = _DATA | 데이타 DD DGROUP:변수명 | = DGROUP | -------------+----------------------+------------------------- 거대 | = 모듈명_TEXT | 코드 DD 변수명 | = 모듈명_DATA | 데이타 DD 변수명 | = 모듈명_DATA | -------------+----------------------+------------------------- * "모듈명"이란 해당 모듈의 원시 화일명(확장자 제외)을 뜻한다. 예컨데 화일명이 dummy.c라면 "모듈명_TEXT"는 "DUMMY_TEXT"가 된다(관례상 대문자를 쓴다). --------------------------------------------------------------------- 6 세그먼트 배치 규칙과 GROUP 의사 명령에 대해 --------------------------------------------------------------------- 세그먼트 배치 규칙과 GROUP 의사 명령에 관해 좀 더 깊이 알고 싶은 독자는, 다음 서적의 제3장 "링크와 세그먼트의 배치"에 보기 드물게 상세 히 설명되어 있으므로 그걸 참고하기 바란다. 하지만 사실 몰라도 프로그 래밍하는 데에는 거의 지장이 없으니까 굳이 부담 느낄 필요는 없을 듯하 다. 황희융 편저, "매크로 어셈블러 활용 1", 교학사 하여튼 지면 사정을 고려하여 이 글에서는 세그먼트 배치와 GROUP 의 사 명령에 관한 설명은 하지 않을 작정이며 할 필요도 없다고 보아, 과감 히 생략하겠다. 독자 여러분도 그냥 일종의 "공식"이라고 생각해 준다면 서로서로 속편할 것 같다. 수학/공학 문제 많이들 풀어 봐서 알겠지만, 공식의 유도 과정을 전혀 몰라도 최종 공식과 그 적용 방법만 알면 대부분 의 문제를 쉽사리 풀어버릴 수 있는 것과 같은 맥락이다. --------------------------------------------------------------------- 7 소형 모델에서의 간단한 예 --------------------------------------------------------------------- <리스트 2> 함수 하나를 가진 가장 간단한 모듈 dummy.c --------------------------------------------------------------------- void dummy(void) { } --------------------------------------------------------------------- <리스트 3>의 dummy.asm은 아래와 같이 tcc.exe를 써서 <리스트 2>을 컴파일한 결과를 실은 것이고, <리스트 4>는 dummy.asm을 <리스트 1>의 양 식에 맞추어 알아보기 쉽게 정리한 것이다. C:\TURBOC\WORK>tcc -S dummy +--- 어셈블리 화일을 생성하도록 지정 <리스트 3> dummy.c를 소형 모델로 컴파일한 결과 --------------------------------------------------------------------- ifndef ??version ?debug macro endm endif ?debug S "dummy.c" _TEXT segment byte public 'CODE' DGROUP group _DATA,_BSS assume cs:_TEXT,ds:DGROUP,ss:DGROUP _TEXT ends _DATA segment word public 'DATA' d@ label byte d@w label word _DATA ends _BSS segment word public 'BSS' b@ label byte b@w label word ---- 디버깅 관련 정보 ?debug C E97615E81406393030382E63 _BSS ends _TEXT segment byte public 'CODE' ; ?debug L 1 --- 행번호 관련 정보 _dummy proc near @1: ← 무의미한 레이블 ; ?debug L 4 ret _dummy endp _TEXT ends ?debug C E9 _DATA segment word public 'DATA' s@ label byte _DATA ends _TEXT segment byte public 'CODE' _TEXT ends public _dummy --- 터보 C는 보통 public 선언을 end 뒷부분에 모아 놓는다. --------------------------------------------------------------------- <리스트4> dummy.asm을 <리스트 1> 양식에 맞춰 정리한 결과 --------------------------------------------------------------------- ;************************************************ ; dummy 모듈의 어셈블리 리스트 ; (소형 메모리 모델) ;************************************************ _TEXT SEGMENT BYTE PUBLIC 'CODE' ASSUME cs:_TEXT,ds:DGROUP,ss:DGROUP +---------+ 소형 데이타 모델에서는 DS와 SS가 일치된다. PUBLIC _dummy ---PUBLIC 선언은 아무 데나 있어도 된다. _dummy PROC NEAR --- 소형 코드 모델일 때 ret --- 아무 일도 하지 않고 곧바로 복귀 _dummy ENDP _TEXT ENDS DGROUP GROUP _DATA,_BSS --- 그룹명 DGROUP의 선언 _DATA SEGMENT WORD PUBLIC 'DATA' d@ LABEL BYTE -+- 이 모듈의 _DATA 세그먼트의 선두를 d@w LABEL WORD -+ 가리키는 일종의 포인터 상수 s@ LABEL BYTE --- 이 모듈의 문자열 상수 영역의 선두를 가리키는 일종의 포인터 상수 _DATA ENDS _BSS SEGMENT WORD PUBLIC 'BSS' b@ LABEL BYTE --- 이 모듈의 _BSS 세그먼트의 선두를 b@w LABEL WORD --- 가리키는 일종의 포인터 상수 (<리스트 8> 참고) _BSS ENDS END --------------------------------------------------------------------- --------------------------------------------------------------------- 8 대형 모델에서의 간단한 예 --------------------------------------------------------------------- <리스트5>의 dummy.asm은 아래와 같이 tcc.exe를 써서 <리스트 2>를 컴파일한 결과를 실은 것이고 <리스트 6>은 dummy.asm을 <리스트 1>의 양 식에 맞게 다시 재정리한 것이다. C:\TURBOC\WORK>tcc -S -ml dummy +--- 대형 모델을 지정 <리스트 5> dummy.c를 대형 모델로 컴파일한 결과 --------------------------------------------------------------------- ifndef ??version ?debug macro endm endif ?debug S "dummy.c" DUMMY_TEXT segment byte public 'CODE' DGROUP group _DATA,_BSS assume cs:DUMMY_TEXT,ds:DGROUP DUMMY_TEXT ends _DATA segment word public 'DATA' d@ label byte d@w label word _DATA ends _BSS segment word public 'BSS' b@ label byte b@w label word ?debug C E97615E8140764756D6D792E63 _BSS ends DUMMY_TEXT segment byte public 'CODE' ; ?debug L 1 _dummy proc far @1: ; ?debug L 4 ret _dummy endp DUMMY_TEXT ends ?debug C E9 _DATA segment word public 'DATA' s@ label byte _DATA ends DUMMY_TEXT segment byte public 'CODE' DUMMY_TEXT ends public _dummy end --------------------------------------------------------------------- <리스트 6> dummy.asm을 <리스트 1> 양식에 맞춰 정리한 결과 --------------------------------------------------------------------- ;************************************************ ; dummy 모듈의 어셈블리 리스트 ; (대형 메모리 모델) ;************************************************ DUMMY_TEXT SEGMENT BYTE PUBLIC 'CODE' ASSUME cs:DUMMY_TEXT,ds:DGROUP SS에 대한 가정이 빠져 있음에 유의---+ PUBLIC _dummy _dummy PROC FAR --- 원거리 함수 ret _dummy ENDP DUMMY_TEXT ENDS DGROUP GROUP _DATA,_BSS _DATA SEGMENT WORD PUBLIC 'DATA' d@ LABEL BYTE d@w LABEL WORD s@ LABEL BYTE _DATA ENDS _BSS SEGMENT WORD PUBLIC 'BSS' b@ LABEL BYTE b@w LABEL WORD _BSS ENDS END --------------------------------------------------------------------- #53 임인건 (turbo28 ) [강좌] C깊은곳4-2: 어셈블리 코드 접속 I 05/06 00:17 286 line --------------------------------------------------------------------- 9 정적 데이타의 정의 --------------------------------------------------------------------- 8086 어셈블리에서 각종 상수 및 변수를 정의할 때에 DB(Define Byt e), DW(Define Word), DD(Define Doubleword) 등을 쓴다는 것쯤은 하도 새 삼스러워서 얘기를 못 꺼내겠다. 다만 유의할 사항은 C 개념에서 볼 때 D W, DD 등에 의한 변수 정의의 대상이 어디까지나 정적 데이타(즉 외부변수 와 정적변수)라는 것이다. 자동변수는 스택상에서 생성소멸하고 레지스터 변수는 레지스터 그 자체이므로 DW나 DD에 의한 정의와는 하등의 상관이 없다. 이와 같이 어셈블리 수준에서 DW나 DD 등에 의해 정의된 변수의 명칭 을, PUBLIC문으로 외부(다른 모듈)에 알리면 C 수준에서의 외부변수가 되 고, 알리지 않으면 외부정적변수(함수 외부에서 정의되는 정적변수)가 되 는 것이다. C의 내부정적변수(함수 내부에서 정의되는 정적변수)는 어셈블 리 수준에서 문법적으로 지원되지는 않는다. 그래서 터보 C는 내부정적변 수를 특별한 방식으로 구현하고 있다. 문자열 상수도 내부정적변수에 준한 다. 실례는 <리스트 8>를 참고하기 바란다. 한편 각종 변수를 어셈블리 수준에서 정의할 때에는 C 수준의 데이타 형이 별 의미가 없다. 그래서 어셈블리 수준에서 중요한 것은 다음의 두 가지 뿐이다. -------------------------------------------------- [1] 데이타 세그먼트에 놓일 정적 데이타이냐? 아니면 스택상에서 생성 소멸될 자동변수이냐? [2] 변수의 크기가 몇 바이트이냐? -------------------------------------------------- 이 절에서는 [1]번 구분에서 정적 데이타의 설명으로 국한하고, 그런 다음 [2]번 구분에 따르자면 이렇다. 즉, 일단 제일 먼저 C의 대표적인 기 본형 및 포인터형의 바이트 크기를 알아야 한다. 다들 알고 있겠지만 다시 한번 <표 2>에 정리해 두었다. 다만 부동형은 어셈블리 수준에서 다루기에 는 너무 벅차므로 생략하고, 그 밖에 배열형 및 구조체형/공용체형은 여기 서 유추해 보면 쉽게 그 크기를 알아낼 수 있을 것이므로 역시 생략한다. <표 2> C의 대표적인 데이타형의 바이트 크기와 그에 따르는 외부변수 및 정적변수의 정의 ------------------------------------------------------------ 크기 지시자 데이타형 ------------------------------------------------------------ 1바이트 DB char, unsigned char 2바이트 DW int, unsigned, enum, 근거리 포인터 4바이트 DD long, unsigned long, 원거리 포인터 ------------------------------------------------------------ * 위와 같이 정의한 뒤 PUBLIC 선언을 하면 외부변수가 되고 그렇지 않으면 정적변수가 된다. 한편 지극히 주의해야 할 것이 딱한 가지 있는데 그것은 포인터 변수 (또는 상수)를 정의할 때이다. 어셈블리 수준에서 포인터가 가리키는 데이 타형은 완전히 무시된다. 즉, 어떤 char *형 포인터와 int *형 포인터가 있을 때, C 수준에서는 컴파일러에 의해 명확하게 서로가 구별되지만, 어 셈블리 수준에서는 문법적으로 전혀 구별되지 않는다. 그래서 어셈블리 수 준에서 포인터의 구분은 딱 두 가지에 의존한다. [1] 근거리 포인터이냐 원거리 포인터이냐? (정규화가 요구되는 거대 포인 터는 C 수준에서만 지원됨) 즉, 2바이트 크기의 포인터이냐 4바이트 크기의 포인터이냐? [2] 근거리 포인터일 경우에 어느 세그먼트에 대한 옵셋이냐? 일반적인 데 이타 포인터(data pointer)라면 DS의 옵셋일 테고 함수 포인터(functi on pointer)라면 CS의 옵셋일 것이다. 그 밖에 _ss, _es 등의 번지지 정 수식자를 쓰면 각각 SS의 옵셋, ES의 옵셋이 될 수도 있다(Turbo C 2.0 User's Guide 354쪽 참고). [1]번의 구분에 의하면 다음과 같이 포인터 변수(또는 상수)를 정의할 수 있다. DW 변수명 --- 근거리 포인터 변수의 정의 DD변수명 --- 원거리 포인터 변수의 정의 위에서 근거리 포인터 변수를 정의할 때에는, 자신이 어셈블리에 대해 도텄다고 생각되지 않는다면, 반드시 어느 세그먼트의 옵셋인지를 명시적 으로 밝히는 것이 합당하다. 밝히는 방법은 <표 1>의 맨 오른쪽 열에 상세 히 언급해 놓았으니, 부디 빠뜨리지 않도록 주의하기 바란다. 많이 쓰이는 소형 및 대형 모델의 경우는 <표 3>에 다시 한번 나열했다. 왜 그래야 하 는가 따지지 말고 그저 공식이라고 생각하고 달달 외우면 골치 썩힐 필요 없어서 좋을 것이다. <표 3> 포인터의 종류에 따른 정의 방법 +--------+----------------------+------------------+ | 초소형 | 근거리 함수 포인터 | DW _TEXT:변수명 | +--------+----------------------+------------------+ | 소형 | 근거리 데이타 포인터 | DW DGROUP:변수명 | +--------+----------------------+------------------+ | 대형 | 원거리 함수 포인터 | DD 변수명 | +--------+----------------------+------------------+ | | 원거리 데이타 포인터 | DD DGROUP:변수명 | +--------+----------------------+------------------+ <표 3>에서 _TEXT는 CS의 옵셋임을 표시하고 DGROUP은 DS의 옵셋임을 표시한다. --------------------------------------------------------------------- 10 외부명칭의 정의에서 주의할 점 --------------------------------------------------------------------- 어셈블리 수준에서의 외부명칭(external identifier)에 속하는 것은 C 수준에서의 외부변수와 (외부)함수의 두 가지 뿐이다. 여기서 외부함수란 정적함수가 아닌 다른 모든 일반적인 함수를 뜻한다. 다른명칭과 달리 외부명칭은 항상 PUBLIC문을 써서 외부(다른 모듈) 에 그 존재를 알려야 함은 이미 잘 알고 있으리라 믿는다. 다만 여기서 주 의할 점은 다음과 같다. +------------------------------------------------+ | 어셈블리 수준에서의 모든 외부명칭은 그 선두에 | | 추가적인 밑줄문자 '_'가 덧붙여져야 한다. | +------------------------------------------------+ "추가적인"이라는 대목에 유의하기 바란다. 따라서 C 수준에서 이미 명칭이 밑줄문자로 시작하더라도 어셈블리 수준에서는 밑줄문자가 추가로 하나 더 붙어야 한다. 예를 들면 다음과 같으며 실례는 <리스트 8>를 참고 하기 바란다. C 수준 어셈블리어 수준 ------------------------- extvar _extvar _extvar __extvar 한편 C에서는 모든 외부명칭(공용(public)명칭 포함)에서 대소문자가 구별되어야 한다(case-sensitive). 따라서 링커를 사용할 때 대소문자를 구별하도록 해야 한다. 대소문자를 구별하도록 링커에게 지시하는 방법은 해당 옵션을 지정하 는 것이다. 터보 어셈블러 tasm와 터보 링커 tlink를 쓸 때에는 각각 /mx, /c 옵션을 지정하면 되고, 매크로 어셈블러 masm과 링커 link를 쓸 때에는 각각 /MX, /NOI 옵션을 지정하면 된다. 자세한 사항은 지면상 다음 회로 미루겠다. --------------------------------------------------------------------- 11 정적 데이터 정의의 실례 --------------------------------------------------------------------- 자, 그럼 이제까지 정적 데이터의 정의에 관해 익힌 것을 총정리해 보 자. <리스트 7>의 statdata.c는 각종 정적 데이터들의 정의를 C로 해 놓은 것이다. <리스트 8>은 아래와 같이 소형 모델에서 statdat.c를 컴파일한 결과인 statdata.asm을 알아보기 좋게 정리한 것이다. C:\TURBOC\WORK>tcc -S statdata <리스트 8>에서 유의할 점은 터보 C가 내부적으로 내부정적변수에 별 도의 명칭을 부여하지 않는다는 점이다. 구체적으로 말해서 독자적인 명칭 을 붙이지 않은 채로 DW, DD 등을 써서 공간만 마련한 뒤, 차후에 참조할 때에는 해당 세그먼트의 선두를 가리키는 d@ 또는 b@에 옵셋을 더해서 참 조한다. 이렇게 함으로써 다른 함수에 그 명칭이 알려지지 않는 효과를 가 져온다. 실례는 <리스트 9>의 _dummy 함수 내의 두번째 mov 명령에서 찾을 수 있다. 이는 문자열 상수가 별도의 명칭 없이 s@로 시작하는 영역에 놓인다는 점과 똑같다. 그래서 문자열 상수는 터보 C에 의해 내부정적변수와 동등하 게 취급된다고 말할 수 있는 것이다. 단지 차이점이라면 문자열 상수는 항 상 ISD에 속한 s@에 놓이는 데 반하여, 내부정적변수는 초기화의 여부에 따라 ISD 또는 UISD 영역에 놓인다는 점만이 다를 뿐이다. 참고로 s@, d@, b@는 각 모듈마다 하나씩 존재하며, 물론 외부명칭이 아니기 때문에 링크 시 서로 충돌하지 않는다. <리스트 7> 각종 정적 데이터의 정의 --------------------------------------------------------------------- /* File STATDATA.C */ int UISDvar; --- 초기치를 명시하지 않았으므로 UISD, 실행 직후 0으로 초기화된다. int ISDvar = 0; --- 초기치가 0이지만 ISD임에 주의 char *neardataptr; --- 근거리 데이터 포인터 char far *fardataptr; --- 원거리 데이터 포인터 void (*nearfuncptr)(void); --- 근거리 함수 포인터 void (far *farfuncptr)(void); --- 원거리 함수 포인터 int extvar; --- 명칭에 밑줄문자가 추가적으로 int _extvar; --- 덧붙음을 확인할 것 static int extstaticvar; --- 외부정적변수 (함수 외부에서 정의된 정적변수) 명칭에 _가 덧붙지 않음을 확인할 것 void dummy(void) { static int instaticvar = 0; --- 내부정적변수 (함수 내부에서 정의된 정적변수) 독자적인 명칭을 가지지 않음을 확인할 것 instaticvar = extstaticvar; } --------------------------------------------------------------------- <리스트 8> <리스트 7>을 어셈블리로 컴파일 한 후 정리한 결과 --------------------------------------------------------------------- ;************************************************ ; statdata 모듈의 어셈블리 리스트 ; (소형 메모리 모델) ;************************************************ _TEXT SEGMENT BYTE PUBLIC 'CODE' ASSUME cs:_TEXT,ds:DGROUP,ss:DGROUP _dummy PROC NEAR mov ax,WORD PTR DGROUP:extstaticvar mov WORD PTR DGROUP:b@,ax ret | _dummy ENDP 내부정적변수는 별도의 명칭을 가지지 않으므로 b@에 옵셋(여기서는 +0)을 더해서 참조한다. _TEXT ENDS DGROUP GROUP _DATA,_BSS _DATA SEGMENT WORD PUBLIC 'DATA' d@ LABEL BYTE --- 초기화된 내부정적변수 영역의 선두를 d@w LABEL WORD --- 가리키는 일종의 포인터 상수 _ISDvar LABEL WORD DW 0 s@ LABEL BYTE --- 문자열 상수들은 이곳에 모아 둔다. _DATA ENDS _BSS SEGMENT WORD PUBLIC 'BSS' b@ LABEL BYTE --- 이 모듈의 _BSS 세그먼트의 선두를 b@w LABEL WORD --- 가리키는 일종의 포인터 상수 DB 2 dup (?) --- 내부정적변수 instaticvar를 위한 공간, 보다시피 명칭이 붙어있지 않다. _extvar LABEL WORD DB 2 dup (?) _UISDvar LABEL WORD DB 2 dup (?) __extvar LABEL WORD --- 밑줄문자가 추가적으로 덧붙여졌다. DB 2 dup (?) _fardataptr LABEL dWORD DB 4 dup (?) _farfuncptr LABEL dWORD DB 4 dup (?) _neardataptr LABEL WORD DB 2 dup (?) _nearfuncptr LABEL WORD DB 2 dup (?) extstaticvar LABEL WORD --- 외부명칭이 아니므로 DB 2 dup (?) 밑줄문자가 덧붙지 않았다. _BSS ENDS _extstaticvar EQU extstaticvar PUBLIC _nearfuncptr PUBLIC _neardataptr PUBLIC _farfuncptr PUBLIC _fardataptr PUBLIC __extvar PUBLIC _UISDvar PUBLIC _extvar PUBLIC _dummy PUBLIC _ISDvar END --------------------------------------------------------------------- --------------------------------------------------------------------- 12 다음에는 --------------------------------------------------------------------- 이번 달에 우리가 알아본 것은 크게 다음과 같은 내용으로 요약할 수 있다. 1. ISD와 UISD의 구분 2. 세그먼트 배치 규칙 및 어셈블리 모듈의 일반적인 양식 3. 정적 데이타(외부변수 및 정적변수)의 정의 4. 외부명칭의 정의에서 주의할 점 아직 이것만으로는 어셈블리 모듈을 작성하기에 역부족이다. 그것은 다음 사항들까지 완전하게 익힌 다음에야 가능해지기 때문이다. 6, 8, 9번 사항은 지난 달에 대충은 언급했었지만 그걸로는 좀 불충분하다. 5. 다른 모듈에 정의되어 있는 외부명칭의 참조 6. (실)매개변수의 참조 7. 자동변수 정의 및 참조 8. C 모듈에서 어셈블리 모듈의 함수 호출 9. 어셈블리 모듈에서 C 모듈의 함수 또는 라이브러리 함수의 호출 10. 어셈블러와 링커의 사용법 지면 사정상 후반부에 대한 얘기는 다음 회로 미뤄야 할 것 같다. 다 음 달이 다가오기 전에 이번 회의 설명을 충분히 소화해 내기를 바라며 이 만 줄일까 한다.