#46 임인건 (turbo28 ) [강좌] C깊은곳1-1: 각종 포인터 05/06 00:02 282 line 마이크로소프트웨어 게재: 1990.5 HWP/TXT 변환: 1993.5.5 >>> 터보 C의 깊은 곳 <<< 제1회 근거리/원거리/거대 포인터의 특징 글/임인건 (서울대 기계공학과4) --------------------------------------------------------------------- 1 본문에 앞서 --------------------------------------------------------------------- 작년 12월을 끝으로 마감된 "정복 터보 C"라는 연재 이후로 개인 사정 때문에 마소에 두문 불출했었는데, 이번에 기회가 닿아서 새로 연재를 시 작하게 되어서 반갑게 생각한다. 그런데 잡지라는 매우 제한적인 환경 탓 으로 인해 한정된 지면에 보다 많은 정보를 축적시키려다 보니 아무래도 글이 딱딱해질 수밖에 없을 것 같아 양해를 먼저 구한다. 이번 연재에서 다룰 내용은, 지난 "정복 ..."와는 달리 중간 과정을 훌쩍 건너뛰어서, 터보 C를 다루는 데 있어서 상당히 고급 기법에 속하는 것들로 꾸밀 생각이다. 최종 목표로는 터보 C와 어셈블리 또는 (사정이 허 락하면) 터보 파스칼과의 링크로 정할 계획이고, 그에 따라 우선은 링크에 앞서 그 기초가 되는 내용을 이번 호와 다음 호에 걸쳐서 다룰 작정으로 있다. 그 기초로서 이 달에는 근거리/원거리/거대 포인터(near/far/huge poi nter)의 특징 및 차이점에 대하여 자세히 알아보고, 다음 달에는 터보 C가 제공하는 6가지의 메모리 모델(memory model)에 관하여 개략적으로 설명한 뒤 그 중에서 특히 소형(small)과 대형(large) 모델에 관하여 집중적으로 알아볼 것이다. 더불어 근거리/원거리 호출(near/far call)의 차이점에 대 해서도 설명할 것이다. 다음으로, 현재까지 이번 연재에 관한 참고 자료로는 Turbo C User's Guide의 마지막 장인 "Advanced Programming in Turbo C"가 거의 유일한 실정이므로 연재의 내용도 그 자료에 준하여 설명할 계획이다. 다만 거기 서 필요없는 내용들을 소폭 삭제하고 빈약한 내용은 대폭 보완하여 독자들 이 터보 C의 깊은 곳까지 이해하는 데 별 어려움이 없도록 할 것이다. 부연하여 이번 연재는 그 특성상 반드시 8086/8088의 각종 구조와 어 셈블리 언어에 대하여 꽤 알고 있으며, 터보 어셈블러나 매크로 어셈블러 의 사용법도 역시 어느 정도까지는 알고 있다고 가정하고 진행할 수밖에 없을 것 같다. 그리고 여태까지는 필자가 글투를 다소 가볍게 했었는데 이 번 연재는 내용이 워낙 기술적이라서 글의 진행에 방해가 되지 않도록 하 기 위해 가급적이면 그런 글투를 자제할 생각으로 있다. --------------------------------------------------------------------- 2 iAPx86군(family) --------------------------------------------------------------------- 다 알다시피 각종 IBM-PC에 쓰이는 CPU는 한 가지가 아니다. 16비트 레지스터에 20비트(1M 바이트)의 번지 지정이 가능한 8086부터 시작해서, 같은 16비트급이지만 8비트 버스를 가지는 8088, 역시 16비트이지만 24비 트(16M 바이트)의 번지 지정이 가능한 80286, 32비트급의 80386, 그리고 8 0386의 기능에 캐쉬 메모리와 수치 보조프로세서를 내장시킨 가장 최근의 i486이 있다. 그 밖에 생소한 80186도 있다. 하지만 이 6개의 CPU들은 모두 운명적으로 8086의 상위 호환성을 가지 고 있고 그들을 총칭하여 iAPx86 또는 80x86군(family)라고 부른다. 때문 에 모든 CPU 상에서 도스가 돌아갈수 있고 따라서 우리는 원조격인 8086 의 구조에 대해서만 집중적으로 캐는 것으로 족하다. 덧붙여서 80286급 이 상에서는 8086과의 호환성을 위해 실제 모드(real mode)라는 것을 지원한 다. 그러므로 앞으로의 모든 내용은 8086 호환의 실제 모드에 관한 것이라 는 것을 전제하니 착오없기 바란다. --------------------------------------------------------------------- 3 8086의 구조 --------------------------------------------------------------------- 8086 어셈블리를 알고 있으면 8086의 구조야 당연히 알고 있겠지만 내 용 전개의 수순을 맞추기 위해서 간략하게나마 8086의 구조에 대하여 언급 을 안 할 수가 없겠다. 3.1 8086의 레지스터 8086에는 16비트 단위로 모두 12개의 레지스터와 거기에 추가로 플랙 레지스터와 IP가 있다. 이 중에서 IP를 제외한 나머지는 터보 C가 직접 제 어할 수 있다. 즉 값을 읽어 낼 수도 있고 CS를 제외한 나머지에는 직접 값을 저장할 수도 있다. 이들 레지스터의 구성은 <그림 1>과 같다. <그림 1> 8086의 레지스터 --------------------------------------------------------------------- 일반 목적의 레지스터 +---------+---------+ AX | AH | AL | 누산기(accumulator) +---------+---------+ BX | BH | BL | 베이스(base) +---------+---------+ CX | CH | CL | 계수(count) +---------+---------+ DX | DH | DL | 데이터(data) +---------+---------+ MSB LSB 세그먼트 레지스터 +-------------------+ CS | | 코드 세그먼트 +-------------------+ DS | | 데이터 세그먼트 +-------------------+ SS | | 스택 세그먼트 +-------------------+ ES | | 여분 세그먼트 +-------------------+ (extra segment) 특수 목적의 레지스터 +-------------------+ SP | | 스택 포인터 +-------------------+ BP | | 베이스 포인터 +-------------------+ SI | | 전송원 색인 +-------------------+ (source index) DI | | 전송지 색인 +-------------------+ (destination index) 플랙 레지스터 +-+-+-+-------+-+-+-+ | | | | o o o | | | | +-+-+-+-------+-+-+-+ MSB LSB --------------------------------------------------------------------- 3.2 터보 C 내부에서의 각 레지스터의 쓰임새 --------------------------------------------------------------------- AX 각종 정수 연산 등에 쓰인다. BX 원거리 포인터(far pointer)의 옵셋(offset)으로 쓰인다. CX 8086의 각종 순환 명령(loop instruction)에 쓰인다. DX 데이터 처리에 관계된 몇몇 명령에 쓰인다. CS DS SS ES 각각 코드, 데이터, 스택, 여분 세그먼트의 시작 번지(패러 그래프 단위)값을 가진다. 이 16비트값들과 지정된 16비트 의 옵셋이 조합되어 20비트의 절대 번지가 만들어진다. SP 스택 세그먼트의 옵셋이며, 스택상에서 가장 꼭대기(가장 낮은 번지)의 현재 위치를 가리킨다. BP 역시 스택 세그먼트의 옵셋이며 SP와는 별도의 보조 역할을 가지는 또 하나의 스택 포인터이다. 터보 C 내부에서는 스 택상에 저장되어 있는 함수의 매개변수 및 자동변수(automa tic variable)를 참조하기 위하여 쓰인다. SI DI 원래는 다른 기능을 가지지만 터보 C에서는 레지스터변수를 지원하기 위해 쓰인다. --------------------------------------------------------------------- --------------------------------------------------------------------- 4 8086의 메모리 관리 방식 --------------------------------------------------------------------- 4.1 세그먼트와 옵셋 8086 CPU는 20비트, 즉 최대 1M바이트의 번지 공간(address space)을 가진다. 그러나 직접적으로는 한번에 64k바이트까지밖에 제어할 수 없도록 설계되어 있다. 그 이유로는 메모리 관리상의 효율과 처리 속도의 증대를 들 수 있겠지만, 원래는 8비트급 8080과의 상위 호환성을 유지하기 위해서 그러한 개념이 도입된 것이다. 8080의 번지 공간은 64k바이트로 제한되어 있지 않은가? 따라서 1M바이트의 공간을 64k바이트의 번지 공간으로 나누 어 효과적으로 제어하기 위해 "세그먼트(segment)"라는 새로운 개념이 도 입된다. 그 개념에 의하면 1M바이트의 공간 중에서 4개의 특정 64k바이트 부분 을 정해서 각각 코드, 데이터, 스택, 여분(extra) 세그먼트라고 부른다. 따라서 최대 256k바이트의 공간을 직접 참조할 수가 있고 그 외의 공간은 직접 참조할 수가 없다. 여기서 코드 세그먼트는 기계어 명령(machine instruction)이 놓여 있 는 곳이고 데이터 세그먼트는 각종 데이터(변수 등)이 놓이는 곳이고, 스 택 세그먼트는 물론 스택이다. 그 밖에 여분 세그먼트는 추가적인 데이터 가 놓이는 곳이며 대개 데이터 세그먼트 공간 외부의 다른 64k바이트 공간 을 직접 참조하기 위하여 쓰인다. 이들 세그먼트는 각각 CS, DS, SS, ES라는 16비트의 세그먼트 레지스 터에 의해 그 시작 번지가 결정된다. 그런 다음 그 시작 번지에 또 다른 1 6비트의 옵셋이 조합되어 20비트의 절대 번지가 얻어진다. 이 때 각 세그먼트의 옵셋으로 쓰이는 레지스터들은 미리 결정되어 있 다. 맨 먼저 IP는 CS의 옵셋이고, SP와 BP는 SS의 옵셋이다. 그 외의 모든 번지 참조 명령은 특별히 지정하지 않는 한 DS의 옵셋으로 간주되며, ES의 옵셋은 특별히 지정하지 않는 한 별도로 존재하지는 않는다. 4.2 절대 번지의 계산 16비트의 세그먼트값과 16비트의 옵셋을 조합하여 20비트의 절대 번지 를 얻기 위해서는 특별한 계산 방식이 사용된다. 예를 들어 데이터 세그먼 트 레지스터(이하 간단히 DS)가 0xb000이고 일반 목적의 BX가 0x05a9라고 하자. 이 두 값으로 절대 번지를 얻기 위해 CPU는 우선 DS를 좌로 4번 쉬 프트시킨다. 즉 DS에 16(0x10)을 곱하여 20비트의 값으로 만든다. 그런 다 음 옵셋을 거기에 더한다. 결과적으로 0xb0000 + 0x05a9 == 0xb05a9가 얻 어진다. <그림 2>를 보기 바란다. 참고로 이 번지는 단색 모니터에서 화면 좌표 (10, 10) 위치의 문자와 그 속성이 저장되어 있는 곳이다. <그림 2> 절대 번지의 계산 --------------------------------------------------------------------- * 세그먼트값 DS (1010 0000 0000 0000) 옵셋 BX (0000 0101 1010 1001) 좌로 4번 쉬프트된 값 * 위의 경우 절대 번지의 계산 방법은... | | 쉬프트된 세그먼트값 (1010 0000 0000 0000 0000) == 0xb000 * 0x10 옵셋 +) (0000 0101 1010 1001) == 0x05a9 -------------------------------------------- (1010 0000 0101 1010 1001) == 0xb05a9 * C의 수식으로 하면 (unsigned long)0xb000 << 4 + 0x05a9 -> 0xb05a9 | +----- 캐스트 연산자가 반드시 필요 --------------------------------------------------------------------- 여기서 알 수 있듯이 세그먼트 레지스터는 항상 1M바이트의 번지 공간 을 16바이트 단위로 건너뛰면서 가리키게 된다. 즉 DS가 0xb000이면 실제 로 DS가 가리키고 있는 번지(데이터 세그먼트의 시작 번지)는 0xb0000이 된다. 쉽게 말해서 세그먼트 레지스터의 값에 16진수로 0을 오른쪽 끝에 덧붙인 값이 실제의 세그먼트 시작 위치가 된다. 참고로 이러한 16바이트 의 단위를 패러그래프(paragraph)라고 부른다. 이 용어에 의하면 우리는 " 세그먼트는 항상 패러그래프 경계에서 시작한다"라고 말할 수 있다. 그런데 절대 번지는 CPU가 계산해서 쓸 따름이고 우리가 실제로 사용 하는 값은 세그먼트와 옵셋의 조합이기 때문에 그에 대한 표기법이 필요해 진다. 세그먼트와 옵셋 조합의 표준 표기법은 다음과 같다. +---------------+ +-----------+ | 세그먼트:옵셋 | 예 | B000:05A9 | +---------------+ +-----------+ 즉 세그먼트와 옵셋의 값을 4자리의 16진수(보통 대문자)로 표기하고 그 사이에 콜론을 하나 삽입하도록 약속이 되어 있다. 한편 세그먼트는 패러그래프 경계라면 어느 곳에서나 시작할 수 있기 때문에 어느 한 절대 번지를 지정하기 위한 세그먼트:옵셋 조합은 유일하 지 않다. 예를 들어서 아래는 모두 똑같이 0xb05a9 번지를 지정하는 조합 들이다. AFFE:05C9 -+ AFFF:05B9 | B000:05A9 | 모두 동일한 0xb05a9번지를 지정한다. B001:0599 | B002:0589 | ...... -+ 이처럼 한 절대 번지를 가리키는 세그먼트:옵셋 조합은 유일하지 않기 때문에 나중에 설명할 여러 가지 문제가 발생하며 그에 따라 세심한 주의 가 필요해진다. --------------------------------------------------------------------- 5 포인터의 분류 --------------------------------------------------------------------- 자, 다시 C로 되돌아가자. C에서 포인터가 차지하는 위치는 실로 막중 하다. 그러나 포인터는 깊이 파고들면 들수록 개념 잡기가 영 힘든 것이 사실이다. 실제로 작년 말 경에 필자는 마소를 통해 포인터라는 단 한 가 지 건수만 갖고 장장 4회에 걸쳐서 C 강좌를 연재한 적이 있다. 여기서는 그 연재에 이어 터보 C가 제공하는 포인터를, 보다 기술적인 면(하드웨어 의존적인 면)에서 심층적으로 파해치고자 한다. 지난 정복 터보 C 강좌에서는 전혀 언급을 안 했지만, 실제로 터보 C가 제 공하는 포인터는 2가지 방법에 의해서 분류할 수 있다. -------------------------------------------------- * 포인터의 대상체(object)에 따른 구분 (예: 문자열 포인터, 배열 포인터 등등) * 포인터가 무슨 세그먼트의 옵셋인가에 따른 구분 (예: 데이터 포인터, 함수 포인터) * 포인터의 바이트 크기와 정규화 여부에 따른 구분 (예: 근거리/원거리/거대 포인터) -------------------------------------------------- 첫번째 분류 방법은 일반적인 것이니까 논외로 하고, 두번째 분류 방 법에 의하면, 함수를 간접적으로 호출하는 데 쓰이는 포인터는 "함수 포인 터"라고 하고 그 외의 모든 포인터, 즉 변수나 배열 등을 간접적으로 조작 하기 위한 포인터들은 "데이터 포인터"라고 총칭한다. 여기서는 세번째 분류 방법에 따라 포인터를 구분하고자 한다. 그 방 법에 따르면 터보 C는 <표 1>과 같이 도합 3종류의 포인터를 제공한다. 이 는 전적으로 8086의 구조에서 파생된, 하드웨어 의존적인 것이다. <표 1> 터보 C가 제공하는 포인터의 종류 세 가지 ------------------------------------------------------ 바이트 크기 번지 공간 정규화 여부 ------------------------------------------------------ 근거리 포인터 2(16비트) 64k바이트 불필요 near pointer 원거리 포인터 4(32비트) 1M바이트 X far pointer 거대 포인터 4(32비트) 1M바이트 O huge pointer ------------------------------------------------------  #47 임인건 (turbo28 ) [강좌] C깊은곳1-2: 각종 포인터 05/06 00:04 269 line --------------------------------------------------------------------- 6 근거리/원거리/거대 포인터의 특징 --------------------------------------------------------------------- 6.1 근거리 포인터(near pointer) IBM-PC의 C에서는 대개 별도로 지정하지 않는 한 포인터는 16비트의 크기를 가진다. 즉 미리 내정된 세그먼트의 16비트 옵셋이다. 그러므로 이 내정된 포인터는 근거리 포인터라고 할 수 있다. 실제로 지난 정복 터보 C 강좌에서 설명한 포인터들은 모두 근거리 포인터들뿐이었다. 이 때 미리 내정된 세그먼트는 근거리 포인터가 데이터 포인터(일반적인 포인터)이냐 함수 포인터이냐에 따라 각각 DS, CS로 결정된다. ------------------------------------------ 근거리 데이터 포인터 : DS의 16비트 옵셋 근거리 함수 포인터 : CS의 16비트 옵셋 ------------------------------------------ 예(소형 데이터 모델에서) char s[10], *ptr; double (*fp)(double); ptr = s; --- ptr은 근거리 데이터 포인터 fp = sin; --- fp는 근거리 함수 포인터 위의 예에서 ptr은 DS 내의 문자 배열 s를 가리키고, fp는 CS 내의 수 학 함수 sin을 가리킨다. 참고로 소형 데이터 모델에서는 항상 DS == SS이 므로 s가 스택상의 자동배열이라 해도 터보 C는 편의상 SS가 아닌 DS 내에 있는 것으로 간주한다. 이 점이 타언어와의 링크에서는 심각한 문제점으로 대두된다. 근거리 포인터의 특징으로는 16비트라는 점 외에도, 우선 사용하기가 쉽다는 장점이 있다. 왜냐 하면 세그먼트가 위와 같이 내정되므로 프로그 래머가 세그먼트에 관해 신경 쓸 필요가 없기 때문이다. 단점은역시 세그 먼트가 DS 또는 CS로 내정되기 때문에 1M바이트의 번지 공간을 모두 참조 할 수 없다는 사실이다. 그러나 이 단점은 상업용 패키지와 같은 대형 프 로그램에서나 중요시될 뿐이고 우리가 일상적으로 작성하는 64k바이트 이 하의 소규모 프로그램에서는 단점이 될 수 없다. 한편 근거리 포인터의 표준 표기법은 다음과 같다. 보통 근거리 포인 터는 DS, CS의 옵셋인 경우가 대부분이지만 매우 특수한 경우에 SS와 ES 옵셋의 근거리 포인터도 만들 수는 있다. +---------+ +---------+ | DS:옵셋 | | CS:옵셋 | +---------+ +---------+ +---------+ 만약 DS == 0xb000이면 예 | DS:05A9 | 절대 번지 0xb05a9를 가리키게 된다. +---------+ 6.2 원거리 포인터(far pointer) 원거리 포인터는 말 그대로 멀리 있는 대상체도 가리킬 수 있는 포인 터이다. 즉 가리킬 수 있는 번지 공간이 64k바이트로 제한되지 않으므로 최대 1M바이트의 공간을 모두 참조할 수 있다. 원거리 포인터는 아래와 같이 32비트, 즉 4바이트의 크기를 가진다. 여기서 원거리 포인터는 자체 내에 세그먼트 정보를 포함하고 있음에 유의 하기 바란다. 32비트 +---------------------+ +-----------+-----------+ MSB | 세그먼트 | 옵셋 | LSB +-----------+-----------+ +---------+ +---------+ 16비트 16비트 원거리 포인터가 메모리에 저장될 때에는 역워드(reverse word) 방식 에 의하여 최하위 바이트부터 최상위 바이트의 순으로 저장된다는 점에 유 의해야 한다. 예를 들어 B000:05A9라면 아래와 같이 저장된다. 낮은 번지 -> 높은 번지 +----+----+----+----+ | A9 | 05 | 00 | B0 | +----+----+----+----+ 6.3 관계 연산식에 원거리 포인터를 사용할 때 반드시 염두에 두어야 할 주의점 세 가지 원거리 포인터를 관계 연산자(==, !=, <, >, <=, >=)와 더불어 사용할 때에는 매우 신중할 필요가 있다. 원거리 포인터의 사용에 익숙치 못한 사 람은 무의식 중에 치명적인 실수를 저지르기가 대단히 쉬우므로 정신 바짝 차리기 바란다. 첫번째, ==와 != 연산자는 양변의 원거리 포인터를 단순히 32비트의 u nsigned long형값으로 간주하고 비교 결과를 구한다. 그래도 별 일 없겠는 가? 여기서 무슨 문제점을 발견하지 못한 사람은 나중에 큰일날 가능성이 농후한 사람이다. 좀 전에 말한 바와 같이 하나의 절대 번지를 지정하는 세그먼트:옵셋 의 조합은 무수히 많다. 그렇기 때문에 만약 두 개의 원거리 포인터를 단 순히 32비트값으로 간주하고 비교를 행한다면, 심각한 문제가 발생할 수 있다. 예를 들어 pa, pb, pc가 각각 AFFF:05B9, B000:05A9, B001:0599의 값 을 가지고 있다고 치자. 그러면 pa, pb, pc는 모두 동일한 절대 번지 0xb0 5a9를 가리키는 포인터가 된다. 하지만 다음 비교 결과는 옳게 얻어질까? if (pa == pb) ...... if (pb == pc) ...... if (pc == pa) ...... 결론부터 말하면 위의 if문 이후의 문장(......부분)은 절대로 실행되 지 않는다. 왜냐 하면 == 연산에서 C는 양변의 원거리 포인터를 unsigned long형으로 간주하므로 위의 연산식들은 각각 0xafff05b9, 0xb00005a9, 0x b0010599를 비교한 결과가 되어, 전부 같지 않다(논리적 거짓)는 결과를 내기 때문이다. 위의 비교가 올바른 결과를 내는 경우는 딱 한 가지뿐이 다. 즉 pa, pb, pc의 세그먼트(상위 2바이트) 부분이 모두 동일할 경우이 다. 덧붙여서 터보 C에서는 unsigned long형과 원거리 포인터의 바이크 구 조가 완전히 동일하다는 점을 참고로 알아 두기 바란다. 두번째, <, >, <=, >= 연산자는 양변의 원거리 포인터가 가지는 세그 먼트값을 완전히 무시한다. 그 대신 옵셋만 가지고 비교를 행한다. 이 연 산자는 한술 더 뜨고 있다는 것을 알 수 있을 것이다. 즉 세그먼트값이야 어쨌든 간에 옵셋만 비교 조건을 만족한다면 논리적 참을 구한다. 예를 들 어 pa는 B000:05A9이고 pb는 B800:05A8이라면 분명히 절대 번지상으로는 p a < pb이지만 아래의 if문 이후는 절대로 실행되지 않는다. if (pa < pb) ...... 왜냐 하면 옵셋만 놓고 볼 때 pa의 옵셋은 pb의 옵셋보다 크기 때문이 다. 이상에서 설명한 바와 같이 관계 연산식에 원거리 포인터에 관계 연산 자를 사용할 때에는 반드시 아래의 관례 1을 명심해야 한다. 만약 이 관례 를 무시하면 나중에 대단히 치명적이고 찾기 힘든 에러를 초래하게 되므로 미리미리 주의하기 바란다. --------------------------------------------------------------------- 관례 1: 관계 연산식에 원거리 포인터를 사용할 때에는 반드시 다음 전제가 만족되어야 한다. +---------------------------------------+ | 관계 연산자 양변의 원거리 포인터는 | | 반드시 그 세그먼트값이 동일해야 한다. | +---------------------------------------+ 양변의 원거리 포인터의 세그먼트값이 동일하다는 전제가 성립된다는 보장이 없을 때, 원거리 연산자를 "직접" 관계 연산자의 피연산자로 사용하면 큰일난다. (거대 포인터를 써야만 한다.) --------------------------------------------------------------------- 세번째, 원거리 포인터에 어떤 정수 값을 더하거나 뺄 때에는 "옵셋만 이 변경됨"에 주의하기 바란다. 즉 세그먼트값은 덧셈, 뺄셈 과정에서 절 대로 변경되지 않는다. 뭐 느끼는 것 없는지 모르겠다. 느끼는 게 전혀 없 는 사람은 아까 말한 바와 같이 큰일날 사람이다. 예를 들어 보자. 만약 원거리 포인터 pa가 B000:FFFF의 값을 가지고 있다고 치자. 그럼 pa++이라는 연산을 수행한 뒤의 pa값을 어떻게 될까? 상식적으로 볼 때 pa는 절대 번지 0xbffff를 가리키므로 pa++를 수행한 뒤 에는 절대 번지로 0xc0000에 상당하는 세그먼트:옵셋 조합이 pa에 저장되 리라고 생각할 수도 있다. 하지만 원거리 포인터에 관한 한 그것은 큰 오 산이다. 왜냐 하면 pa의 옵셋만이 증가되기 때문이다. pa의 옵셋은 0xffff이다. 이 값을 1 증가시키면 어떻게 될까? 혹시 0 x10000이 된다고 생각한 사람이 있는가? 만에 하나 그렇다면 비트, 바이 트라는 용어부터 공부를 다시해야 할 것이다. pa의 옵셋은 16비트의 값이다. 이 값을 1 증가시키면 비록 상식적으로 는 0x10000이 되지만 16비트인 까닭에 그 범위를 초과하는 최상위 1비트가 잘려나간다. 따라서 결과는 0x0000이 된다. 결국 pa++의 결과는 B0000:0000이 되어 절대 번지로는 0xc0000이 아니 라 0xb0000이라는 엄청난 차이를 가져온다. 이는 신중에 신중을 기하지 않 으면 자칫 실수하기가 매우 쉬운 사항이므로 주의에 주의를 요한다. 주의 사항을 요약하면 다음 관례 2와 같다. --------------------------------------------------------------------- 관례 2: 원거리 포인터에 어떤 정수값을 가감할 때에는 반드시 다음 조건이 만족되어야 한다. +------------------------------------------------+ | 원거리 포인터에 어떤 정수값을 더한 결과는 | | 절대로 세그먼트의 경계를 벗어나지 않아야 한다. | +------------------------------------------------+ 즉 옵셋이 0x0000보다 작아지거나 0xffff보다 커질 가능성이 있으면, 절대로 원거리 포인터에 "직접" 정수값을 더하거나 빼서는 안 된다. (거대 포인터를 써야만 한다.) --------------------------------------------------------------------- 6.4 거대 포인터(huge pointer) 원거리 포인터를 사용할 때에는 이상에서 설명한 바과 같은 세 가지 문제점이 발생하기 때문에 그에 따라 관례 1, 2에서 제시한 바와 같이 사 용상에 몇몇 제약이 따른다. 그런데 보통 한번에 64k바이트 이하의 데이터 를 처리할 경우라면 그런 문제점은 원거리 포인터 자체만으로도 극복할 수 있다. 하지만 64k바이트를 초과하는 대용량의 데이터를 처리해야만 할 경우 나 임의의 크기의 데이터를 처리해야 할 경우에는 그런 문제점들 때문에 원칙적으로 원거리 포인터를 쓸 수가 없다. 그런 경우를 대비하여 터보 C 는 거대 포인터(huge pointer)라는 특이한 포인터를 제공한다. 거대 포인터는 포인터가 거대하다는 뜻이 아니라 정규화된 포인터(nor malized pointer)를 뜻한다. 결론부터 말해서, 정규화된 거대 포인터를 사 용하면 원거리 포인터가 가지는 세 가지 문제점이 일거에 해소되므로 이론 상 최대 1M바이트의 데이터까지 처리가 가능하다. 그렇다면 정규화가 무엇이냐? 여태껏 얘기한 바와 같이 하나의 절대 번지를 지정하는 세그먼트:옵셋 조합은 무수히 많다. 정규화(normalizatio n)란 어떤 규칙을 정하여 그러한 무수한 조합을 하나로 통일함으로써 "하 나의 절대 번지에는 단 하나만의 세그먼트:옵셋 조합이 대응되도록 하는 것"이다. 그 규칙은 간단하다. 알다시피 세그먼트는 16바이트 단위로 절대 번지 를 가리킨다. 따라서 옵셋은 실제로 0-15의 값만 가져도 충분하다. 그러므 로 어떤 세그먼트와 옵셋이 주어져 있을 때 옵셋의 하위 4비트를 제외한 나머지 비트 12비트를 세그먼트에 더해 줌으로써 옵셋의 상위 12비트를 0 으로 만들면 정규화가 끝난다. 예를 들어 B000:05A9라는 조합이 있을 때 정규화는 아래 그림 3과 같 은 과정을 거쳐 이루어진다. <그림 3> 거대 포인터의 정규화 과정 --------------------------------------------------------------------- 세그먼트 옵셋 B000 05A9 --- 절대 번지 0xb05a9를 가리킨다. | | | +---+---+ | | | | 05A 9 --- 하위 4비트만을 따로 떼어낸다. | | | +---+---+ | | 서로 | | 더한다 | B05A 0009 --- 정규화된 후에도 | | 절대 번지 0xb05a9를 가리킨다. | | 정규화된 정규화된 세그먼트값 옵셋 --------------------------------------------------------------------- 거대 포인터는 원거리 포인터와 달리 매 연산마다 그 직후에 정규화된 다는 차이점이 있다. 또한 터보 C는 <, >, <=, >=같은 관계 연산자의 양변 이 거대 포인터일 경우에 원거리 포인터와 달리 32비트값을 전부 비교한 다. 즉 옵셋은 물론이고 세그먼트값까지 비교한다. 따라서 거대 포인터를 사용하면 원거리 포인터 사용시 발생하는 세 가 지 문제점을 일거에 해소할 수 있다. 즉 관계 연산자를 사용할 때에나 정 수값을 더할 때 상식을 벗어나는 어떠한 문제점도 없이 올바른 결과가 얻 어진다. 6.5 원거리 포인터와 거대 포인터의 선택 거대 포인터가 그러하다면 원거리 포인터는 결코 쓸 필요가 없지 않느 냐고 반문할 수도 있다. 하지만 거대 포인터는 치명적인 단점이 하나 있 다. 그것은 원거리 포인터에 비해 연산 실행 속도가 현저하게 저하된다는 점이다. 이것은 속도가 생명인, 특히 대용량의 데이터 처리에서는 더더욱 절싱한 컴퓨터 프로그램에서는 용납하기 힘든 점이다. 그래서 원거리 포인터가 사용하기에 대단히 조심스럽다 하더라도 거대 포인터에 비해 그 처리 속도가 워낙 빠르기 때문에 C 프로그래머들은 위험 부담을 무릅쓰고 원거리 포인터를 쓰는 것이다. 다만 원거리 포인터를 사용하려면 반드시 한번에 최대 64k바이트까지 의 데이터밖에 처리하지 못한다는 점을 감안해야 한다. 그것은 원거리 포 인터 연산 과정에서 세그먼트값은 고정되고 옵셋만이 바뀌기 때문이다. 따 라서 64k바이트를 초과하는 데이터를 한번에 처리해야 할 필요가 있다면 반드시 거대 포인터를 써야 한다. 그러나 그렇게 큰 데이터를 처리할 기회가 독자에게 주어질 가능성은 극히 희박하므로 아마도 거대 포인터를 쓸 일은 좀처럼 없을 것으로 본다. 하지만 정규화를 해야 할 때는 심심치 않게 생길것이다. 왜냐 하면 세그 먼트값이 동일하지 않은 두 개의 원거리 포인터를 비교해야 할 때에는 반 드시 정규화를 시킨 뒤에야 가능하기 때문이다. 차후에 다시 설명하겠지만 그런 의도적인 정규화는 특별한 캐스트 연산자를 써서 이루어진다. --------------------------------------------------------------------- 7 다음에는 --------------------------------------------------------------------- 이번 달에는 8086의 구조, 근거리/원거리/거대 등 3가지 포인터의 특 징과 차이점, 그리고 원거리 포인터 사용시의 주의할 사항 등을 알아보았 다. 사실 이번 달에 터보 C가 제공하는 메모리 모델까지 설명하려 했지만 지면 사정과 필자 개인 사정이 겹쳐서 부득이하게 다음 달로 미루게 됐다. 다음 달에는 계속해서 터보 C가 제공하는 6개의 메모리 모델에 관하여 설 명하고 근거리/원거리/거대 포인터를 선언하는 방법에 대하여 보다 알찬 설명으로 이야기를 이끌어 나가겠다. <제1회 끝>  #48 임인건 (turbo28 ) [강좌] C깊은곳2-1: 메모리 모델과 그 구조 05/06 00:08 484 line 마이크로소프트웨어 게재: 1990.6 HWP/TXT 변환: 1993.5.5 >>> 터보 C의 깊은 곳 <<< 제2회 터보 C의 각종 메모리 모델과 그 구조 글/임인건 (서울대 기계공학과4) --------------------------------------------------------------------- 1 본문에 앞서 --------------------------------------------------------------------- 지난 달에는 터보 C가 제공하는 세 종류의 포인터, 즉 근거리/원거리/ 거대 포인터의 특징과 사용시 주의 사항에 대하여 설명했다. 이번에는 그 포인터들을 이해하는 데에 필수적인 사항인 "메모리 모델(memory model)" 의 구조/특징/차이점에 관하여 설명하겠다. 미리 말하지만 이번 글은 상당 히 기술적인 내용 일색이라서 맑은 정신으로 임해야지만 끝까지 성공적으 로 완독해 낼 수 있을 것이다. 결코 가볍게 훑어볼 만한 내용은 아니다. 그리고 한 번 읽고 이해하려고 너무 성급하게 덤비지도 말기 바란다. 최소 한 서너번은 읽어야 감이 잡힐 것으로 본다. --------------------------------------------------------------------- 2 터보 C의 메모리 모델 개요 --------------------------------------------------------------------- 터보 C는 도합 6 종류의 메모리 모델을 제공한다. 초소형(tiny), 소 형, 중형, 중소형, 대형, 거대 모델 등이 그것이다. 이들의 구분은 CS, D S, SS, ES 등 네 개의 세그먼트를 어떻게 관리하느냐에 달려 있다. 프로그 래머는 자신의 상황에 알맞게 이들 중에서 메모리 모델을 선택하여 프로그 램을 작성하게 된다. 이들 모델의 개략적인 설명을 하자면 다음과 같다. 나중에 다시 깔끔 하게 비교/정리해 놓을 테니 지금은 그냥 그려려니 하고 대충 훑어보기만 하기 바란다. 무슨 말인지 언뜻 가슴에 와 닿지 않더라도 말이다. 2.1 소형 데이터 모델 [1] 초소형 모델(tiny model) 말 그대로 가장 작은 메모리 모델이다. 이 모델에서는 모든 세그먼트 레지스터가 동일한 번지에 위치하며 프로그램 실행의 전과정을 통털어 고 정적이다. 즉 "항상 CS == DS == SS == ES"이다. 따라서 이 모델에서는 총 64k바이트(축소 가능)의 메모리 공간만이 코드, 데이터, 스택을 위해 할당 된다. 나머지 640k바이트 공간은 직접적으로 제어할 수 없다. 그 밖에 "모 든 포인터는 근거리 포인터로 내정"되는 특징이 있으며, 유일하게 이 모델 만이 .COM 화일을 생성해 낼 수 있다. 그것은 exe2bin.exe 유틸리티를 사 용하거나 터보 링커에 /t 옵션을 지정함으로써 가능하다. 램상주 프로그램 을 제작할 때에는 이 모델을 쓰는 것이 일반적이다. [2] 소형 모델(small model) 이 모델에서는 DS == SS == ES이지만 CS != DS이다. 즉 코드 세그먼트 와 데이터 및 스택 세그먼트가 분리된다. 따라서 초소형 모델에서와는 달 리 스택 또는 데이터가 코드 영역을 침범할 염려가 (정상적인 경우) 절대 없다. 이 모델에서는 최대 64k바이트의 코드 영역과 총 64k바이트(축소 가 능)의 데이터/스택 영역이 존재하며, 결과적으로 최소 64k(축소 가능), 최 대 128k의 메모리를 직접적으로 사용할 수 있다. "모든 포인터는 근거리 포인터로 내정"되며, 대부분의 응용 프로그램에서 이 모델은 적당한 크기 를 가진다. 실제로 터보 C에서는 별도의 컴파일러 옵션을 지정(변경)하지 않는 한 소형 모델이 내정된다. [3] 중형 모델(medium model) 함수 포인터는 원거리 포인터로 내정된다. 따라서 코드는 64k바이트를 가뿐히 초과할 수 있다. 단, 모듈별 분할 컴파일을 해야만 초과가 가능하 다는 전제가 있기는 하다. 하지만 데이터 포인터는 근거리 포인터로 내정 되므로 데이터 및 스택은 총 64k바이트(축소 가능)의 공간을 차지한다. 이 모델은 데이터를 별로 쓰지 않는 대형 프로그램에 적당하다(실제로는 별로 안 쓰임). 참고로 함수 포인터가 원거리 포인터로 내정된다는 말은 모든 함수 호출이 원거리 호출(far call)로 내정된다는 뜻도 포함한다. 2.2 대형 데이터 모델 [4] 중소형 모델(compact model) 이 모델은 중형 모델의 반대이다. 즉 데이터 포인터로 원거리 포인터 가 내정되고, 함수 포인터는 근거리 포인터로 내정된다. 그리고 함수 호출 은 원거리 호출로 내정된다. 따라서 코드는 최대 64k바이트를 초과할 수 없으며, 데이터 포인터로 1M바이트 공간(힙 포함)을 직접적으로 참조할 수 있다. 하지만 정적 데이터는 최대 64k바이트를 초과할 수 없다. 한편 코 드, 데이터, 스택 세그먼트는 각각 독립적으로 존재하며 겹쳐지지 않는다. 이 모델은 코드는 작은 반면 데이터가 대단히 많은 프로그램에 유용하다 (실제로는 별로 안 쓰임). [5] 대형 모델(large model) 함수 포인터와 데이터 포인터로 원거리 포인터가 내정된다. 그리고 함 수 호출은 원거리 호출로 내정된다. 따라서 코드의 분량은 모듈별 분할 컴 파일을 통해 (이론상) 최대 1M바이트까지 가능하고, 데이터 포인터도 역시 1M바이트 공간(힙 포함)을 직접적으로 참조할 수 있다. 하지만 정적 데이 터는 최대 64k바이트를 초과할 수 없다. 한편 코드, 데이터, 스택 세그먼 트는 각각 독립적으로 존재하며겹쳐지지 않는다. 이 모델은 대단히 큰 프 로그램에 쓰이며, 실제로 실행 화일의 크기가 대략 64k바이트 이상인 대부 분의 C 응용 프로그램은 이 모델이라고 보면 거의 틀림없다. [6] 거대 모델(huge model) 64k바이트 이상의 정적 데이터를 가질 수 있다는 것을 제외하고는 대 형 모델과 똑같다. 64k바이트 이상의 정적 데이터를 가질 수 있도록 하기 위해 함수 호출은 거대 호출(huge call)로 내정된다. 하지만 함수 포인터 와 데이터 포인터는 실행 속도를 고려하여 대형 모델처럼 원거리 포인터로 내정된다는 데 주의해야 한다. 이 모델은, 예컨데 대용량의 자형(font) 데 이터를 실행 화일 자체 내에 포함시키고자 할 경우 등에나 쓰이고 보통의 경우에는 거의 쓰이지 않는다. --------------------------------------------------------------------- 3 각 모델들의 메모리 지도 --------------------------------------------------------------------- 다음의 <그림 1>~<그림 6>은 각 모델들의 메모리 지도(memory map)이 다. 여기서 주의해서 살펴볼 것은 아래와 같다. * CS, DS, SS의 상등 여부 및 고정적인가의 여부 * 각 세그먼트의 놓인 순서 (항상 CS <= DS <= SS의 순서임) * 각 세그먼트 크기의 최대 한계 * 정적 데이터 영역의 구조 (항상 초기화된 데이터 -> 비초기화된 데이터의 순서) * 스택 영역의 구조 * 근거리/원거리 힙의 위치 * 스택 및 힙의 성장 방향, 즉 위(하위 번지)쪽이냐 아래(상위 번지)쪽이냐. 한편, 그림에서 위쪽은 하위 번지이고 아래쪽은 상위 번지이다. 또한 겹으로 된 수평선은 독립된 세그먼트의 경계를 나타냄에 특히 주목하여 보 기 바란다. 그 외의 수평선은 해당세그먼트 내 각 영역의 경계를 나타낼 뿐이다. 이는 각 메모리 모델의 구조를 이해하는 데 상당히 중요한 사항이 므로 가능한 한 생각하는 자세로 그림을 보아 줬으면 싶다. 참고로 정적 데이터(static data)란 모든 종류의 외부변수, 정적변수 및 문자열 상수 등을 총칭하는 말이다. 이 때 원시 코드상에서 그 초기치 를 명시한 정적 데이터는 특별히 "초기화된 데이터(initialized data)"라 부르고 명시적으로 초기화되지 않은 데이터는 "비초기화된 데이터(uniniti alized data)"라고 부른다. 둘 사이의 차이점은 이렇다. 즉 초기화된 데이터의 값은 실행 화일 내 에 포함되는 반면에, 비초기화된 데이터의 값은 실행 화일 내에 포함되지 않으며 프로그램이 실행됨과 동시에 기동 코드(startup code)에 의해 0으 로 초기화된다(단, 거대 모델에서는 비초기화된 데이터 영역이 별도로 존 재하지 않으며 모두 초기화된 데이터로 간주한다). <그림 1> 초소형 모델(tiny model)의 메모리 지도 --------------------------------------------------------------------- CS, DS, SS ---> +-------------------+-+ (ES == DS)(1)| | | | 코드 | | | | | +-------------------+ |-+ | 초기화된 데이터 | | | |-------------------| | |(2) | 비초기화된 데이터 | | | +-------------------+ |-+ | 근거리 힙(4) | | |-------------------| | 정확히 64k바이트(3) | | | | 여유 공간 | | | | | |-------------------| | <--- SP(가변) | 스택 | | +-------------------+-+ <--- SP 초기치 (1) 원거리 포인터를 전혀 쓰지 않을 경우에만. (2) 두 영역을 합해 "정적 데이터 영역"이라 부른다. (3) 메모리가 모자라면 그에 맞게 자동적으로 축소되며 외부변수 _stklen, _heaplen의 초기치를 변경하여 의도적으로 64k바이트 이하로 축소시킬 수 있다. (램상주 프로그램 등에서) (4) malloc, calloc/free 함수를 써서 할당/해제한다. * 초소형 메모리에서도 원거리 힙이 있을 수 있지만 실제 사정상 거의 쓰이지 않으므로 그림에 나타내지 않았다. --------------------------------------------------------------------- <그림 2> 소형 모델(small model)의 메모리 지도 --------------------------------------------------------------------- CS ---> +-------------------+-+ | | | | 코드 | | 최대 64k바이트까지 | | | +-------------------+-+-+ (ES == DS) | 초기화된 데이터 | | | (1) |-------------------| | |(2) | 비초기화된 데이터 | | | +-------------------+ |-+ | 근거리 힙(4) | | | near heap | | |-------------------| | 정확히 64k바이트(3) | | | | 여유 공간 | | | | | |-------------------| | <--- SP(가변) | 스택 | | +-------------------+-+ <--- SP 초기치 | 원거리 힙(5) | | | far heap | | |-------------------| | | | | | 여유 공간 | | | free space | | 남는 메모리 끝까지 +-------------------+-+ (1)(2)(3)(4) 초소형 모델 참고 (5) farmalloc/farfree 함수 또는 allocmem/freemem 함수를 써서 할당/해제한다. --------------------------------------------------------------------- <그림 3> 중형 모델(medium model)의 메모리 지도 --------------------------------------------------------------------- +- 함수 호출(원거리 호출)시에만 | 그 함수가 존재하는 모듈의 | 세그먼트 선두를 가리키도록 변경되며 | 그 외에는 고정적이다. | CS -+-> +-------------------+-+ | | 모듈1 | | +-> +-------------------+-+ | | 모듈2 | | +-> +-------------------+-+ 각 모듈 최대 64k바이트까지 | | ......| | +-> +-------------------+-+ | 모듈n | | DS, SS ---> +-------------------+-+-+ (ES == DS) | 초기화된 데이터 | | | (1) |-------------------| | |(2) | 비초기화된 데이터 | | | +-------------------+ |-+ | 근거리 힙(4) | | |-------------------| | 정확히 64k바이트(3) | | | | 여유 공간 | | | | | |-------------------| | <--- SP(가변) | 스택 | | +-------------------+-+ <--- SP 초기치 | 원거리 힙(5) | | |-------------------| | | | | | 여유 공간 | | 남는 메모리 끝까지 +-------------------+-+ (1)(2)(3)(4)(5) 초소형 모델 참고 * 지도에서 복선은 독립된 세그먼트의 경계를 나타내며 단선, 또는 점선은 동일한 세그먼트 내에서 각 영역의 경계를 나타낸다. (다른 그림에서도 마찬가지) --------------------------------------------------------------------- <그림 4> 중소형 모델(compact model)의 메모리 지도 --------------------------------------------------------------------- CS ---> +-------------------+-+ | | | | 코드 | | 최대 64k바이트까지 | | | DS ---> +-------------------+-+ (ES == ??) | 초기화된 데이터 | | (1) |-------------------| | 최대 64k바이트까지(2) | 비초기화된 데이터 | | SS ---> +-------------------+-+ | 여유 공간 | | 4k바이트(3) |-------------------| | <--- SP(가변) | 스택 | | +-------------------+-+ <--- SP 초기치 | (원거리) 힙(4) | | |-------------------| | | | | | 여유 공간 | | 남는 메모리 끝까지 +-------------------+-+ (1) ES는 원거리 포인터를 위해 쓰이며 그때그때 값이 변한다. (2) 두 영역을 합해 "정적 데이터 영역"이라 부른다. (3) 외부변수 _stklen을 재정의하여 변경할 수 있다. (4) 근거리 힙이 따로 존재하지 않으므로 그냥 힙이라고 부른다. malloc,calloc/free 함수에 의해 해제/설정한다. --------------------------------------------------------------------- <그림 5> 대형 모델(large model)의 메모리 지도 --------------------------------------------------------------------- +- 함수 호출(원거리 호출)시에만 | 그 함수가 존재하는 모듈의 | 세그먼트 선두를 가리키도록 변경되며 | 그 외에는 고정적이다. | CS -+-> +-------------------+-+ | | 모듈1 | | +-> +-------------------+-+ | | 모듈2 | | +-> +-------------------+-+ 각 모듈 최대 64k바이트까지 | | ...... | | +-> +-------------------+-+ | 모듈n | | DS ---> +-------------------+-+ (ES == ??) | 초기화된 데이터 | | (1) |-------------------| | 최대 64k바이트까지(2) | 비초기화된 데이터 | | SS ---> +-------------------+-+ | | | 4k바이트(3) |-------------------| | <--- SP(가변) | 스택 | | +-------------------+-+ <--- SP 초기치 | (원거리) 힙(4) | | | heap | | |-------------------| | | | | | 여유 공간 || | free space | | 남는 메모리 끝까지 +-------------------+-+ (1)(2)(3)(4) 중소형 모델 참고 --------------------------------------------------------------------- <그림 6> 거대 모델(huge model)의 메모리 지도 --------------------------------------------------------------------- +- 대형 모델 참조 | CS -+-> +-------------------+-+ | | 모듈1 | | +-> +-------------------+ | | | 모듈2 | | +-> +-------------------+ | 각 모듈의 코드 | | ...... | | 최대 64k바이트까지 +-> +-------------------+ | | 모듈n | | DS -+-> +-------------------+-+ | | 모듈1의 데이터 | | (ES == ??) +-> +-------------------+ | (1) | | 모듈2의 데이터 | | +-> +-------------------+ | 각 모듈의 데이터 | | ...... | | 최대 64k바이트까지 +-> +-------------------+ | (2) | 모듈n의 데이터 | | SS ---> +-------------------+-+ | | | 4k바이트(3) |-------------------| | <--- SP(가변) | 스택 | | +-------------------+-+ <--- SP 초기치 | (원거리) 힙(4) | | |-------------------| | | | | | 여유 공간 | | 남는 메모리 끝까지 +-------------------+-+ (1)(3)(4) 중소형 모델 참고 (2) 초기화된 데이터만을 의미한다. 비초기화된 데이터 영역은 별도로 존재하지 않는다. --------------------------------------------------------------------- --------------------------------------------------------------------- 4 메모리 모델의 분류 --------------------------------------------------------------------- <표 1> 메모리 모델의 분류 -------------+--------------------------------------------------- | 코드 크기(code size) 데이터 크기 +---------------------+----------------------------- (data size) | 64k 이하 | 1M 이하 -------------+---------------------+----------------------------- | 초소형 | 64k 이하 | (코드, 데이터 중첩) | | 소형 | 중형 | (코드, 데이터분리) | -------------+---------------------+----------------------------- | 중소형 | 대형 1M 이하 | | (정적 데이터 64k 이하) | | 거대 | | (정적 데이터 64k 초과 가능) -------------+---------------------+----------------------------- <표 1>에 각종 메모리 모델을 그 대표적인 특징에 따라 분류해 놓았 다. 이와 같이 코드나 데이터 크기의 한계에 따라서 메모리 모델을 분류하 는 것이 가장 일반적이다. 그런데 살다 보면 코드나 데이터 크기에 따라 이들을 총칭하는 용어가 자주 필요해지는데, 이에 따라 그러한 용어들을 아래와 같이 정의해서 쓰고 있다. * 데이터 크기에 따른 분류 - 소형 데이터 모델: 초소형, 소형, 중형 - 대형 데이터 모델: 중소형, 대형, 거대 * 코드 크기에 따른 분류 - 소형 코드 모델: 초소형, 소형, 중소형 - 대형 코드 모델: 중형, 대형, 거대 --------------------------------------------------------------------- 5 각 메모리 모델의 특징 --------------------------------------------------------------------- 앞 절의 용어를 써서 각종 메모리 모델의 특징을 사안별로 비교/설명 하면 다음과 같다. <그림 1>~<그림 6>을 참고하면서 세심하게 따져 보기 바란다. --------------------------------------------------------------------- * 내정된 포인터 - 소형 데이터 모델: 근거리 포인터(near pointer) - 대형 데이터 모델: 원거리 포인터(far pointer) (거대 모델에서도 원거리 포인터가 내정됨에 주의!) * 내정된 포인터의 바이트 크기 - 소형 데이터 모델: 2바이트 - 대형 데이터 모델: 4바이트 * 내정된 함수 호출 방식 - 소형 코드 모델: 근거리 호출(near call) - 중형/대형 모델: 원거리 호출(far call) - 거대 모델: 거대 호출(huge call) (거대 호출은 함수 호출 직전에 그 함수가 존재하는 모듈에 딸린 독립적인 데이터 세그먼트의 선두를 DS가 가리키도록 그 값을 변경함을 뜻한다. <그림 6> 참고) --------------------------------------------------------------------- * 데이터(힙 포함)의 총 크기 - 소형 데이터 모델: 최대 64k바이트까지(근거리 힙 포함) - 대형 데이터 모델: (이론상) 최대 1M바이트까지(힙 포함) * 정적 데이터 영역(외부변수/정적변수/문자열 상수)의 크기 - 소형 데이터 모델: 최대 64k바이트까지 - 중형/대형 모델: 최대 64k바이트까지(요주의!!!) - 거대 모델: (이론상) 최대 1M바이트까지 (단, 각 모듈의 정적 데이터 크기는 64k바이트를 초과할 수 없다!!) * 코드의 총 크기 - 소형 코드 모델: 최대 64k바이트까지 -대형 코드 모델: (이론상) 최대 1M바이트까지 (단, 각 모듈의 코드 크기는 64k바이트를 초과할 수 없다!!) --------------------------------------------------------------------- * 각 세그먼트의 배치 - 초소형 모델: CS == DS == SS == ES - 소형 모델: CS < DS == SS == ES - 중형 모델: CS < DS == SS == ES - 중소형 모델: CS < DS < SS ES == ?? - 대형 모델: CS < DS < SS ES == ?? - 거대 모델: CS < DS < SS ES == ?? * 코드/데이터 세그먼트의 중첩(overlap) 여부 - 초소형 모델만 겹치고(CS == DS) 나머지는 모두 독립적으로 분리됨(CS < DS) * 데이터/스택 세그먼트의 중첩 여부 - 소형 데이터 모델: DS == SS - 대형 데이터 모델: DS < SS, 즉 독립적으로 분리됨 * CS 값의 가변 여부 - 소형 코드 모델: CS == 코드 세그먼트의 선두 == 고정 불변 - 대형 코드 모델: CS는 서로 다른 모듈에 있는 함수를 (원거리) 호출할 때마다 해당 모듈의 세그먼트 선두를 가리키도록 변경된다. 그 외에는 고정적. * DS 값의 가변 여부 - 거대 모델: 서로 다른 모듈에 있는 함수를 (원거리) 호출할 때마다 해당 모듈에 속하는 정적 데이터 영역의 세그먼트 선두를 가리키도록 변경된다(-> 거대 호출). 그 외에는 고정적. - 그 외의 모델: DS == 정적 데이터 영역의 세그먼트 선두 == 고정 불변 * ES 값의 가변 여부 - 소형 데이터 모델: ES == DS == 고정 불변 (단, 원거리 포인터를 사용하지 않았을 경우) - 대형 데이터 모델: ES == ?? == 가변 (원거리 포인터를 위해 쓰인다) --------------------------------------------------------------------- * 근거리 힙(near heap)의 크기 - 초소형 모델: (데이터 세그먼트의 크기) - (코드 크기) - (정적 데이터 영역) - (사용된 스택 크기) - 소형/중형 모델: (데이터 세그먼트의 크기) - (정적 데이터 영역) - (사용된 스택 크기) (데이터 세그먼트의 크기는 외부변수 _heaplen이 0(내정치)일 경우 정확히 64k(65536)바이트이고, 만약 외부변수 _stklen과 _heaplen의 초기치를 프로그램에서 지정한 경우 64k바이트 이하로 줄일 수 있다. 더불어 메모리가 부족할 때에도 데이터 세그먼트의 크기가 그에 알맞게 줄어든다. Turbo C Reference Guide 매뉴얼 참조) - 대형 데이터 모델: 근거리 힙이 존재하지 않는다. --------------------------------------------------------------------- * 특별히 컴파일러 옵션을 변경하지 않았을 때 내정되는 메모리 모델 - 소형 모델이 내정된다. 따라서 일반적인 경우 근거리 포인터/근거리 호출이 내정되며 코드와 데이터 세그먼트는 분리된다. ---------------------------------------------------------------------  #49 임인건 (turbo28 ) [강좌] C깊은곳2-2: 메모리 모델과 그 구조 05/06 00:09 288 line --------------------------------------------------------------------- 6 번지지정 수식자(addressing modifier) --------------------------------------------------------------------- 터보 C는 ANSI C 사양에 기초하지 않은 7개의 수식자(modifier)를 추 가로 제공한다. near, far, huge, _cs, _ds, _es, _ss 여기서 뒤의 4개는 다른 언어(특히 파스칼)과의 링크에서나 필요한 것 이므로 설명을 생략하고, 대신 앞의 3개에 관해서 중점적으로 설명하겠다. 터보 C에서는 포인터나 함수 호출의 내정된 방식을 프로그래머가 임의로 변경할 수 있다. 예컨데 소형 데이터 모델에서는 근거리 포인터가 내정되 지만 프로그래머는 원거리 포인터를 쓰기 위해 포인터의 데이터형을 변경 할 수 있다. 이처럼 내정된 포인터형이나 함수 호출 방식을 변경시키고자 할 때 (주로) near, far, huge 수식자가 쓰인다. 여기서 near, far 등등을 수식자라 부르는 이유는 포인터형임을 나타내는 구두점 *를 문법적으로 수 식하는 역할을 하기 때문이다. --------------------------------------------------------------------- 7 근거리/원거리/거대 포인터의 정의 --------------------------------------------------------------------- 예를 들어서, (char *)형 포인터(문자열 포인터) str이 소형 데이터 모델에서 아래와 같이 정의되어 있다고 치자. 그러면 str은 근거리 포인터 로 내정된다. char *str; 이 때 str을 원거리 포인터로 바꾸려면 "*"를 "far *"로 치환하면 된 다. 즉 수식자 far를 구두점 * 앞에 놓으면 된다. char far *str; 만약 대형 데이터 모델에서 str을 근거리 포인터로 정의하고 싶다면, char near *str; 이라고 기술하면 된다. 거대 포인터를 원한다면 near 대신에 huge를 쓰는 것으로 족하다. 일반적으로 어떤 데이터형 T가 있고 T형 데이터를 가리키는 포인터 pt r이 아래와 같이 정의되어 있을 때(ptr은 꼭 변수명일 필요가 없다), T *ptr; ptr의 내정된 포인터형을 변경시키고자 하면 "*ptr"을 "near *ptr", "far *ptr", "huge *ptr"로 그대로 치환하기만 하면 된다. 이 때 (ptr이 변수명 이 아닐 때) 필요하면 아래와 같이 ptr에 괄호를 두름으로써 *나 [ ], ( ) 등의 구두점의 우선 순위에 변동이 생기기 않도록 해야 한다. 그 외의 다 른 부분은 건드리면 안 된다. T near *ptr; T far *ptr; T huge *ptr; T near *(ptr); T far *(ptr); T huge *(ptr); 예를 들어 소형 모델에서 이차원 배열 포인터 py가 아래와 같이 정의 되어 있을 때, int ss[3][10]; int (*py)[10]; py = ss; py를 원거리 포인터로 데이터형을 변경하려면 아래와 같이 한다. int (far *py)[10]; 다음은 포인터의 포인터(포인터를 가리키는 포인터)를 정의한 예이다. char **pps; ppx를 원거리 포인터를 가리키는 원거리 포인터로 바꾸면 아래와 같 다. char far *(far *pps); 또는 괄호를 제거하여 char far *far *pps; 만약 위의 정의를 "char far **ppx"라고 하면 소형 데이터 모델에서는 "char far *near *ptr"이 되어 결과적으로 "원거리 포인터를 가리키는 근 거리 포인터"가 되므로 주의하기 바란다. 다음은 각종 원거리/거대 포인터를 정의한 예이다. 포인터 변수의 원 래 데이터형은 "far *"이나 "huge *"를 "*"로 재치환하면 쉽게 파악할 수 있을 것이다. int far *px; ← 일차원 배열 포인터(원거리) char huge *px; ← 문자열 배열 포인터(거대) int (far *fp)(double x); ← 함수 포인터(원거리) double (far *py)[100]; ← 이차원 배열 포인터(원거리) void far *ptr; ← void형 원거리 포인터 --------------------------------------------------------------------- 8 끝으로 --------------------------------------------------------------------- 이번 달의 글은 독자들에게 지루함 내지 당혹한 감이 없지 않았을 줄 로 안다. 아직까지도 얘기가 실질적인 부분에 접어들지 못했기 때문에, 예 제도 없이 설명을 강행해 나갈 수밖에 없었다. 게다가 글이 워낙 기술적이 라서 한번에 많은 분량의 글을 게재하기도 뭐한 탓도 있었다. 다음 달에는 근거리/원거리/거대 호출 방식의 특징 및 차이점에 대해 알아보고, 더불어 소형 모델과 대형 모델에 국한하여 스택 영역을 64k바이 트 이하로 축소시키는 방법과 세그먼트 각 부분의 위치(가령 데이터 세그 먼트의 크기, 힙의 선두 번지 등등)를 알아내는 비법을 소개하겠다. 물론 다음 달부터는 조금은 실질적인 설명과 예제가 이어질 것이므로 지루하지 않게 눈으로 확인하면서 터보 C의 깊은 곳을 파헤쳐 나갈 수 있을 것이다. --------------------------------------------------------------------- 9 덤으로 --------------------------------------------------------------------- 아무런 예제도 없이 그냥 글을 마치려니까 아무래도 떨떠름해서 덤으 로 최고급 난이도의 예제를 하나 소개한다. 다음의 예제 memmodel.c는 소 형 모델에서의 실제적인 메모리 지도를 보여 준다. 터보 C의 깊은 곳을 눈 으로 직접 확인할 수 있는 좋은 기회가 아닐까 생각한다. 메모리 지도를 얻기 위해서는 메모리 각 영역의 시작과 끝 번지(또는 세그먼트 경계)를 알아야 하는데 이 예제에서는 시작과 끝 번지를 구하기 위하여 한 가지 이상의 방법을 사용하고 있다. 실행 결과를 보면 여러 가 지 방법에 의해 구한 번지값들이 서로 완전하게 잘 일치하고 있음을 볼 수 있을 것이다. 이 예제는 반드시 터보 C 2.0에서 소형 모델(내정치 그대로)로 컴파일 /링크해야 한다. 다음의 실행 결과는 터보 C 2.0 통합 개발 환경하에서 컴 파일러 옵션을 전혀 변경하지 않은 채(디버깅 모드 상태)로 그 결과를 출 력한 것이다. 참고로 이 예제는 데이터 세그먼트의 크기를 내정치인 64k바이트보다 축소시키기 위하여, 스택의 크기를 설정하는 외부변수 _stklen의 초기치를 0x0250으로, 근거리 힙의 크기를 설정하는 외부변수 _heaplen의 초기치를 0x0001로 잡아, 기동 코드(startup code)로 하여금 데이터 세그먼트의 크 기를 대폭 축소시키도록 했다. 자세한 사항은 Turbo C 2.0 Reference Guid e 매뉴얼 28쪽, 30쪽을 참고하기 바란다. 지면 사정상, 시간 관계상 이 예제의 분석은 다음 달로 미룰 수밖에 없을 것 같다. 그러나 서투른 영어지만 주석을 충분히 달아 두었으므로 의 욕만 있다면 예제를 분석하는 게 어렵지만도 않을 것이다. 다만 go_up_sta ck 함수는 스택을 꺼꾸로 거슬러 올라가서 SP의 초기치(스택의 최상위 번 지값)를 구해 주는 함수로서, 이 함수는 터보 C 패키지에 딸려 있는 기동 코드 c0.asm의 어셈블리 원시 화일을 분석하지 않고는 전혀 이해할 수가 없기 때문에, 지금은 그냥 그려려니 하기 바란다. 그 외의 나머지 부분은 독자 스스로 분석해 낼 수 있으리라 믿는다. 발등이 찍힐지는 모르겠지 만... <예제 MEMMODEL.C> 소형 모델에서의 실제적인 메모리 지도 --------------------------------------------------------------------- /* File MEMMODEL.C */ #include #include #include #pragma warn -par /* off warning */ unsigned _heaplen = 0x0001; /* minimum value */ /* if _heaplen == 0 or _heaplen is too large, this program will output wrong results */ unsigned _stklen = 0x0250; /* minimum value is 0x0200 when the software emulation for the floating point operation */ extern unsigned _psp; /* program segment prefix */ /* declared in dos.h */ extern void *__heapbase; /* a pointer to the near heap base */ extern void *__heaptop; extern void far *_heapbase; /* a pointer to the far heap base */ extern void far *_heaptop; void *go_up_stack(unsigned BP, int argc, char *argv[]) { int i; BP += 2; /* for "push bp" in the main function */ BP += 2; /* for return address when quit the main function (small code model) */ BP += 6; /* for argc, argv, envp(6 byte) */ BP += argc * 2; /* for argv[0], ..., argv[argc - 1] */ BP += 2; /* for argv[argc](== NULL) */ for (i = 0; i < argc; i++) /* for strings pointed by argv[i]s */ BP += strlen(argv[i]) + 1; if ((BP & 0x0001) != 0) BP++; /* for word alignment(dummy 0x00 byte)*/ BP += 2; /* for dummy return address(== 0x00fb) */ return (void *)BP; /* BP is the initial value of SP */ /* sometimes BP == StartingSP - 2 because of the additional dummy return address(2 byte) */ } void main(int argc, char *argv[], char *env[]) { unsigned CSsize; /*code segment size in paragraph(small model) */ unsigned DSsize; /* data segment size in paragraph */ unsigned StartingSP; /* initial value of SP */ unsigned farheap; /* segment of the far heap base pointer */ unsigned keepsize; /* calculated keep size in paragraph, i.e. total program size */ void *ptr; void far *topofmem; /* far pointer to the top of the memory */ CSsize = _DS - _CS; /* when small model */ ptr = (char *)__heapbase + _stklen + _heaplen; DSsize = ((unsigned)ptr >> 4) + 1; StartingSP = DSsize << 4; farheap = FP_SEG(_heapbase); /* get segment of the _heapbase */ keepsize = farheap - _psp; /* print the structure of the small memory model */ printf("Porgram segment prefix == %#06x\n", _psp); printf("Code segment == %#06x\n", _CS); printf("Data segment == %#06x\n", _DS); printf("Stack segment == %#06x\n", _SS); printf("Extra segment == %#06x\n", _ES); printf("Offset of static data area to DS == 0x0000\n"); printf("Offset of near heap base to DS == %#06x\n", __heapbase); printf("Offset of near heap top to DS == %#06x\n", __heaptop); printf("Current stack pointer == %#06x\n", _SP); /* print the initial value of SP calculated by three different methods */ printf("Initial value of SP == %#06x\n", StartingSP); printf(" == %#06x(other method)\n", (farheap - _DS) << 4); printf(" == %#06x(other method)\n", go_up_stack(_BP, argc, argv)); /* print the map of the far heap */ topofmem = MK_FP(*(unsigned far *)MK_FP(_psp, 0x0002), 0x0000); printf("Far heap base == %Fp\n", _heapbase); printf("Far heap top == %Fp\n", _heaptop); printf("Top of memory == %Fp\n\n", topofmem); /* print sizes */ printf("CS size == %#06x paragraph\n", CSsize); printf("DS size == %#06x paragraph(including stack)\n", DSsize); printf("Keep size == %#06x paragraph\n", keepsize); printf(" == %#06x(other method)\n", 0x10 + CSsize + DSsize); printf("Free space in near heap == %#06x byte(including stack area)\n", _SP - (unsigned)__heaptop + 1); printf("Free space in far heap == %ld byte\n", (unsigned long)(FP_SEG(_heaptop) - FP_SEG(_heapbase)) << 4); printf(" == %ld byte(other method)\n", (unsigned long)(FP_SEG(topofmem) - FP_SEG(_heapbase)) << 4); /* for a TSR program "keep(0, keepsize);" is required before quit program */ } --------------------------------------------------------------------- 실행 결과 (터보 C 2.0 통합 개발 환경하에서 소형 모델로 컴파일/링크/실행. PSP의 세그먼트값 등이나 원거리 힙의 크기 등은 시스템 상황에 따라 가변적이다. 그러나 상대적인 값은 시스템에 상관없이 일정하리라 본다.) Porgram segment prefix == 0x847e Code segment == 0x848e Data segment == 0x85e6 Stack segment == 0x85e6 Extra segment == 0x85e6 Offset of static data area to DS == 0x0000 Offset of near heap base to DS == 0x079a Offset of near heap top to DS == 0x079a Current stack pointer == 0x09ba Initial value of SP == 0x09f0 == 0x09f0(other method) == 0x09f0(other method) Far heap base == 8685:0000 Far heap top == A000:0000 Top of memory == A000:0000 CS size == 0x0158 paragraph DS size == 0x009f paragraph(including stack) Keep size == 0x0207 paragraph == 0x0207(other method) Free space in near heap == 0x0221 byte(including stack area) Free space in far heap == 104368 byte == 104368 byte(other method) --------------------------------------------------------------------- <제2회 끝>  #50 임인건 (turbo28 ) [강좌] C깊은곳3-1: 함수 호출/C 호출 관행 05/06 00:11 361 line 마이크로소프트웨어 게재: 1990.7 HWP/TXT 변환: 1993.5.5 >>> 터보 C의 깊은 곳 <<< 제3회 함수 호출의 실제와 C 호출 관행 글/임인건 (서울대 기계공학과4) --------------------------------------------------------------------- 1 본문에 앞서 --------------------------------------------------------------------- 지난 달에는 터보 C가 제공하는 6개 메모리 모델(memory model)의 구 조/특징/차이점에 관하여 설명했다. 이번에는이어서 터보 C가 제공하는 3 가지 함수 호출 방식과 더불어 함수에 매개변수를 전달하는 순서에 대하여 자세히 설명하겠다. --------------------------------------------------------------------- 2 일단 감부터 잡고 보자 - C 함수 호출의 숨겨진 내막 --------------------------------------------------------------------- 다음의 <예제 1>은 소시적의 파스칼이 코웃음칠 만한, 구석기 시대적 인 정수 합산 프로그램이다. 이 예제에서 main 함수는 sum이라는 함수를 호출한다. 이 때 sum 함수는 int형 매개변수를 2개 취하고, int형 값을 되 돌려준다. 그리고 sum 함수는 2개의 int형 자동변수를 마련하여 내부적으 로 쓰고 있다. 여기서 주의할 사항은 어떤 함수이든지 그 선언문에 나타나는 최초의 2바이트 크기(int형, unsigned형, 근거리 포인터)의 자동변수 2개는 터보 C의 최적화(optimizing)에 의해 레지스터변수로 자동 변환된다는 점이다. 이 때 레지스터변수는 터보 C 내부적으로 SI와 DI 레지스터를 의미한다. 이 점을 파악하지 못하면 <예제 2>를 이해할 수 없게 된다. 물론 그러한 최적화는다른 레지스터변수의 정의가 없을 때에 한하며, 또한 번지 연산자 &의 피연산자로 단 한 번이라도 쓰이는 2바이트 크기의 자동변수는 순서상 비록 최초일지라도 레지스터변수로 자동 변환되지 않는 다. 그것은 레지스터변수의 경우 그 번지를 취할 수 없기 때문이다. <예제 1> 아주 간단한 예제 --------------------------------------------------------------------- #include int sum(int n1, int n2) { +--+------------ 최적화에 의해 자동적으로 int n; | 레지스터 변수(SI와DI)가 된다. int sum = 0; --- 함수명과 자동변수명은 중복되도 무방하다. for (n = n1; n <= n2; n++) sum += n; return sum; } void main(void) { int result; result = sum(0, 10); printf("Result = %d\n", result); } --------------------------------------------------------------------- 다음의 <예제 2>는 tcc.exe를 써서 <예제 1>을 어셈블리로 컴파일한 뒤에 중요한 부분만 발췌/편집한 것으로서, 터보 C에서 함수를 호출하고 값을 복귀(return)하는 이른바 "호출 관행(calling convention)"의 전말을 보여 주고 있다. 즉 함수 호출/피호출 규칙 및 매개변수의 전달 순서 등이 적나라하게 드러나 있다. 이미 어셈블리에서의 함수(프로시져) 호출 방식 등에 익숙해 있는 독자는 <예제 2>만으로도 몇 달 분량의 원고를 다 읽은 셈이 될 것이다. <예제 2> <예제 1>을 어셈블리로 컴파일한 코드 --------------------------------------------------------------------- ...... ; ; sum 함수(PUBLIC 선언은 다른 곳에 모아져 있다) ; _sum PROC near --- 근거리 함수임을 나타낸다. 진입 +-push bp --- BP를 대피시킨다. 코드 +-mov bp,sp --- BP는 매개변수와 자동변수를 참조하기 위한 포인터로 쓰인다. push si -+- 함수 내에서 SI와 DI를 쓰려면 반드시 push di -+ SI와 DI의 이전 값을 대피시켜야 한다. xor di,di --+ mov si,word ptr [bp+4] | jmp short @5 매개변수n1 | @4: | sum 함수 블럭 내의 add di,si | 문장들을 컴파일한 @3: | 어셈블리 코드 inc si | @5: | cmp si,word ptr [bp+6] | jle @4 매개변수n2 -+ @2: mov ax,di --- 2바이트 크기의 데이터형은 jmp short @1 AX에 넣어 복귀한다. @1: pop di -+- SI와 DI의 이전 값을 복구 pop si -+ 탈출 +-pop bp--- BP의 이전 값을 복구 코드 +-ret _sum ENDP ; ; main 함수 ; _main PROC near +-- 함수 내부에서 SI를 쓰므로 push si ----+ 이전 값을 대피시킨다. (main 함수도 기동 코드에 대한 피호출 함수임) +-mov ax,10 | push ax ------- 두번째 실매개변수 10의 저장 sum | xor ax,ax ---- 첫번째 실매개변수 0의 저장 호출 | push ax ------- 근거리 호출(near call) | call near ptr _sum | pop cx -+----- SP의 원상 복귀 +-pop cx -+ (pop 명령을 썼음에 주목) mov si,ax --- 반환값을 result(즉 SI)에 대입 +-push si 문자열 "Result = %d\n"을 가리키는 printf| mov ax,offset DGROUP:s@ --+ 포인터 호출 | push ax +--- 다음 달에 설명할 예정 | call near ptr _printf | pop cx +-pop cx pop si -------- 이전 값을 복구 ret --------------- 프로그램의 실행을 종료한다 _main ENDP (실제로는 기동 코드의 종료 루틴으로 프로그램 제어를 넘긴다) ...... --------------------------------------------------------------------- --------------------------------------------------------------------- 3 호출 함수와 피호출 함수의 의미 --------------------------------------------------------------------- 본론에 들어가기 전에 우선 새로운 용어 두 가지만 확실히 하고 넘어 가자. <예제 1>를 보면 main 함수가 sum 함수를 호출하고 있다. 여기서 그 호출한 시점에서만 국한하여 볼 때, main 함수를 "호출 함수"라고 하고 su m 함수를 "피호출 함수"로 부르기로 하자. 굳이 영어로 하자면 각각 "call ing function", "called function"이 되겠다. 유의할 점은 호출 함수와 피호출 함수의 관계가 그 호출하는 시점에 국한되어 결정지어진다는 것이다. 그래서 시점을 바꾸면 그 관계도 달라진 다. 예를 들어 만약 sum 함수가 또 다른 함수를 호출한다면 그 시점에서는 sum이 호출 함수가 된다. 그리고 main 함수도 프로그램 실행 직후로 시점 을 달리 하면 기동 코드(startup code)에서 호출되는 피호출 함수이다. 그 밖에 복귀(return), 대피(push), 복구(pop), 반환값(리턴값; retur n value) 등의 용어도 생소한 독자는 익혀 두기 바란다. --------------------------------------------------------------------- 4 근거리/원거리/거대 함수 --------------------------------------------------------------------- 4.1 C와 어셈블리의 링크에 앞서 한편, <예제 2>를 훑어보고 "대충 그런거구나!"하고 이해가 간다면 곧 바로 이 글의 최종 목표인 C와 어셈블리의 링크에 관한 이야기를 풀어도 무리가 없겠지만, 논리의 흐름을 위해 일단은 함수 호출 방식을 비롯한 제 반 사항에 대한 설명이 먼저 있어야 할 것 같다. 우리는 C로 프로그램을 짤 때 함수명 다음에 괄호를 두르고 실매개변 수들을 나열하면 C 컴파일러가 그 함수를 알아서 적당한 방법으로 호출해 주므로 실제로(어셈블리어 수준에서) 함수가 어떻게 호출되는지는 사실상 알 필요가 없었다. 하지만 C와 어셈블리를 링크하려면 그 호출 방법을 모 르고서는 함수를 호출할 수가 없다. 왜냐 하면 어셈블리 루틴은 C 컴파일 러와 별개의 존재이기 때문이다. 여담이지만... 우리가 숟가락으로 밥 한 술을 뜰 때 과연 어떻게 하고 있는지 생각해 보고 먹는 사람이 있는가? 숟가락을 쥘 때에 얼마마한 압 력을 가해야 숟가락이 미끄러 떨어지지 않고, 숟가락을 몇 뉴튼의 힘으로 어떤 방향에서 밥풀 더미에 쑤셔 넣어야 숟가락이 밥풀 더미의 저항으로 이기고 파고들 수 있는가, 그리고 손목에 얼마 만한 모멘트를 가해야 숟가 락이 밥을 퍼낼 수 있으며, 팔과 손목을 몇 자유도로 어떠한 경로로 얼마 만한 속도로 이동시켜야 최단 시간 내에 퍼낸 밥을 단 한 톨 흘리지 않고 목적지인 입에 접근시킬 수 있는가... 게다가 그런 동작을 취하기 위해 대 뇌에서 각 조직의 신경 섬유에 어떠한 전기적 펄스를 가해야 하느냐에까지 다다르면 정말 밑도 끝도 없다. 이런 걸 생각해 본 적이 있는가 말이다. 물론 거의 전무하겠지. 사람이라면 그런 건 본능적으로 "자연스럽게" 처리 할 수 있을 테니 당연하다. 하지만 만약에 밥 한 술을 뜨는 로보트 팔을 만든다고 해보라. 아니면 시뮬레이션도 좋다. 그렇다면 얘기는 전혀 달라질 것이다. 왜냐 하면 로보 트는 본능이란 게 없으니깐. 그러므로 좀 전에 언급한 모든 것이 심각한 고려 대상이 된다. 결론적으로 봐서 그 밥 한 술 뜨는 어찌보면 하찮고 간 단한 동작을 해석하기 위하여 수십 수백명의 천재가 동원되어야 할 것이 다. 이것을 C와 어셈블리의 관계에서도 그럴 듯하게 비유된다. C 언어로 프로그래밍할 때에는 내부적인 복잡한 처리를 C 컴파일러가 알아서 "자연 스럽게 해결(컴파일)"해 주므로 전혀 대수롭지 않게 생각되던 것이, 어셈 블리로 할 때에는 하나부터 열까지 모든 것을 프로그래머가 책임지고 해 나가야 한다. 따라서 발생하는 어려운 일이 한두 가지가 아니다. 반드시 준수해야 할 규칙도 부지기수이고, 또한 벌레잡는 데(디버깅) 드는 고충도 이만저만이 아니다. 이런 점을 염두에 두고, C와 어셈블리의 링크에는 이처럼 어려운 일이 산적해 있다는 것을 미리 파악한 뒤에 이 글을 읽어 나간다면, 세세하고 쪼존한 수많은 규칙들을 익히는 데 드는 부담감은 어느 정도 줄일 수 있으 리라 본다. 4.2 근거리 호출(near call) 먼저 가장 간단하고 가장 일반적인 근거리 호출에 관하여 알아보자. 근거리 호출의 가장 특징적인 점은 피호출 함수(근거리 함수)가 본연의 임 무를 성공리에 마치고 원래 자신을 호출했던 함수로 복귀(리턴)할 때, 스 택으로부터 "2바이트의 복귀 번지"를 취한다는 것이다. 어셈블리 코드로 이를 나타내면 다음과 같다. * 근거리 함수(near function)의 정의 PUBLIC _func _func PROC near ← 근거리 함수임을 표시 ...... ret --- 2바이트의 복귀 번지(IP)를 취한다. _func ENDP * 근거리 호출(near call) call near ptr _func | +-- 스택에 2바이트의 복귀 번지만을, 즉 IP만을 대피시킨다. 4.3 원거리 호출(far call) 그 다음으로 원거리 호출의 가장 특징적인 점은 피호출 함수(원거리 함수)가 일을 모두 끝마치고 복귀할 때, 스택으로부터 "4바이트의 복귀 번 지"를 취한다는 것이다. 어셈블리 코드로 이를 나타내면 다음과 같다. * 원거리 함수(far function)의 정의 PUBLIC _func _func PROC far --- 원거리 함수임을 표시 ...... ret ---4바이트의 복귀 번지(CS:IP)를 취한다. _func ENDP * 원거리 호출(far call) 같은 모듈 내의 함수 호출시 ← 작은 글자체!! push cs call near ptr _func 다른 모듈 내의 함수 호출시 ← 작은 글자체 call far ptr _func | +-- 스택에 4바이트의 복귀 번지를, 즉 CS:IP를 대피시킨다. (주의)위의 호출 방식이 아래보다 처리 속도가 빠름. 그러나 결과는 완전히 동등함. 4.4 거대 호출(huge call) 거대 호출은 함수 호출 방법에 관한 한 사실상 원거리 호출과 완전히 동일(identical)하다. 더욱이 어셈블리 수준에서는 "문법적으로" 원거리 호출과 거대 호출이 전혀 구별되지 않는다. 다만 원거리 호출과의 차이점이라면 피호출 함수(거대 함수)가 그 선 두에서 DS의 값을 일단 대피시킨 후에, 자신이 속해 있는 모듈의 정적 데 이터 영역 선두로 DS를 변경한다는 것이다. 그런 후 일을 모두 끝마치면 원래의 DS 값을 복구한 다음 4바이트의 복귀 번지(CS:IP)를 취하여 되돌아 간다. 이처럼 DS가 고정적이지 않기 때문에 터보 C의 6개 메모리 모델 중 에서 유일하게 64k 이상의 정적 데이타를 취할 수 있는 모델이 되는 것이 다. 어셈블리 코드로 이를 나타내면 대략 다음과 같은데, 거대 함수는 어 셈블리와의 링크에서는 실제로 거의 쓰이지 않을 것이므로 그런데 있구나 하는 정도로만 알아 두면 될 것 같다. * 거대 함수의 정의(작성) PUBLIC _func _func PROC far ...... push ds mov ax, 모듈명_DATA mov ds,ax | ...... +-- 해당 모듈의 정적 데이터 영역의 pop ds 선두를 가리키는 포인터. ...... ret _func ENDP * 거대 호출(원거리 호출과 완전히 동일) 같은 모듈 내의 함수 호출시 push cs call near ptr _func 다른 모듈 내의 함수 호출시 call far ptr _func --------------------------------------------------------------------- 5 근거리/원거리/거대 함수의 선언(정의) --------------------------------------------------------------------- 5.1 함수 수식자 near/far/huge 지금까지는 어셈블리 코드로 예를 들었는데 C 문법적으로도 근거리/원 거리/거대 함수를 선언 및 정의할 수 있다. 그 방법도 간단해서, 함수 선 언 또는 정의에서 void, int, double 따위의 함수형 지정자(type specifie r)와 함수명 사이에 near/far/huge라는 함수 수식자(function modifier) 중의 하나를 삽입하는 것으로 끝난다. 예를 들어 <예제 1>의 sum 함수를 원거리 함수로 정의하려면 아래와 같이 바꾸면 된다. 다른 모든사항은 평상시와 똑같다. * 원거리 함수의 정의 int far sum(int n1, int n2) { ...... } * 원거리 함수의 선언 int far sum(int n1, int n2); 일반적인 경우에 near/far/huge 등의 함수 수식자는 쓸 일이 거의 없다. 그것은 메모리 모델에 따라서 적절한 함수 호출 방식이 내정되기 때문이 다. 자세한 사항은 저번 달에 지루하도록 자세히 설명한 바 있으므로 새삼 스럽게 재론하지는 않겠다. 다만 대형 코드 모델에서 속도상의 문제로 인해 특별히 근거리 함수가 필요할 할 때 near를 쓰기도 하고, 반면에 터보 C가 제공하는 그래픽 함수 들과 같이 소형 코드 모델에서도 반드시 원거리 호출을 해야만 하는 경우 에 그 선언문 등에 far를 기술하기도 함을 참고하기 바란다. 지금 당장 터 보 C 참조 안내서(매뉴얼)를 보기 바란다. 아마 그래픽 함수는 몽땅 그 원 형에 far 수식자를 포함하고 있을 것이다. 덧붙여서 그래픽 함수는 메모리 모델에 상관없이 단 한 벌만이 마련되 어 있기 때문에 호환성을 위해 모두 원거리 함수로서 작성되어 있다. 5.2 선언/정의할 때 주의할 점 한편, 주의할 점은 반드시 함수명 직전에 near/far/huge를 삽입해야 한다는 것이다. 다른 곳에 삽입하면 수식자의 의미가 전혀 틀려진다. 예를 들어 아래의 세 선언문은 서로 완전히 다른 의미를 가지고 있다. [1] char *far func1(void); [2] char far *func2(void); [3] char far *far func3(void); | | | +-- func3가 원거리 함수임을 나타내는 | 함수 수식자(function modifier) +-- func3의 반환값이 원거리 포인터임을 나타내는 번지지정 수식자(addressing modifier) 위의 선언들은 각각 아래와 같은 의미를 가지고 있다. [1] (내정된 크기의) char *형 포인터를 복귀하는 원거리 함수 func1을 선 언 [2] char far *형 포인터를 복귀하는 (내정된 호출 방식의) 함수 func2를 선언 [3] char far *형의 포인터를 복귀하는 원거리 함수 func3를 선언 여기서 "내정된 크기"란 소형 데이터 모델에서는 근거리 포인터, 그 밖에는 원거리 포인터로 내정됨을 뜻하고, "내정된 호출 방식"이란 소형 코드 모델에서는 근거리 함수, 거대 모델에서는 거대 함수, 그 밖에는 원 거리 함수임을 뜻한다. 세 가지 선언이 잘 구별되지 않는다면, 책을 잠시 덮어 두고 장마로 우중충한 하늘이나마 한번 물끄러미 쳐다본 뒤에 저번 달 글부터 차분히 다시 읽어 보면 자연스럽게 이해가 되리라 본다.  #51 임인건 (turbo28 ) [강좌] C깊은곳3-2: 함수 호출/C 호출 관행 05/06 00:13 437 line --------------------------------------------------------------------- 6 매개변수 전달 방식 2가지의 개요 --------------------------------------------------------------------- 이상에서는 함수의 호출/복귀라는 관점에서 주로 설명을 진행했다. 이 번에는 함수를 호출할 때 과연 실매개변수(actual parameter 또는 argumen t)를 어떠한 순서로 스택에 대피(저장)시키느냐 하는 관점에서 설명을 하 겠다. 참, 함수에 매개변수를 전달하는 방법으로서 거의 대부분의 고급 언 어에서 스택이 활용된다는 것쯤은 익히 알고 있으리라 믿는다. 피호출 함수에 매개변수를 전달하는 순서는 아래와 같이 딱 2가지 방 법에 의한다. +----------------------------------------+ | [1] C 방식 매개변수 전달 순서 | | C Parameter-Passing Sequence | | 또는 C 호출 관행 | | C Calling Convention | | | | [2] 파스칼식 매개변수 전달 순서 | | Pascal Parameter-Passing Sequence| | 또는 파스칼 호출 관행 | | Pascal Calling Convention | +----------------------------------------+ 이 중에서 후자는 터보 파스칼같은 고급 언어와의 링크에서나 필요한 것이므로 지금 당장은 알아 둘 필요가 없다. 반면에 전자는 터보 C(사실상 IBM-PC에서 돌아가는 대부분의 C)가 표준 라이브러리 함수들을 비롯한 모 든 함수의 호출할 때의 내정(default)된 방식이므로, C와 어셈블리의 링크 를 위해선 전자의 방식을 학실하게 파악해 둘 필요가 있다. 이 두 방식간의 가장 큰 차이점은 첫째, 실매개변수를 스택에 저장하 는 순서이고 둘째, 복귀 후에 스택 포인터 SP값의 복구를 호출 함수와 피 호출 함수 중 어느 쪽이 담당하느냐 하는 것이다. 두번째 사항은 곧 매개 변수의 갯수가 필요에 따라 가변적일 수도 있느냐 아니면 항상 고정적이냐 하는 것을 의미하기도 한다. 추가로 아주 근소하고 보통 무시할 수 있는 호출/복귀 처리 속도의 차이도 있다. 그러면 이제부터 C 방식 매개변수 전달 순서에 대하여 차분히 알아보 기로 하자. --------------------------------------------------------------------- 7 C 방식 매개변수 전달 순서 - C 호출 관행 --------------------------------------------------------------------- 예를 들어 아래와 같은 원형(prototype)을 가진 함수가 정의 및 선언 되어 있다고 치자. 여기서 함수 본체(body)는 아무래도 상관없다. 주목할 것은 매개변수의 전달 방식이나까. void funca(int p1, int p2, long p3); 내정적으로 터보 C는 C 방식 매개변수 전달 순서에 의한다. 이는 다른 말로 "C 호출 관행"이라고도 흔히 일컫는다. 위의 함수 funca가 다음과 같 이 호출되었을 때, void main(void) { funca(0x1122, 0x3344, 0x55667788); } 호출 함수(즉 main)쪽의 각 실매개변수 0x1122, 0x3344, 0x55667788은 "모 두" 스택에 대피(저장)된다. 이 때 대피 순서는 "오른쪽->왼쪽"임에 유의 하기 바란다. 그런 다음에 마지막으로 복귀 번지(return address)가 스택 에 대피된 후 funca로 프로그램 제어가 옮겨진다. 자, 그런 연후에 스택은 어떻게 되었을까? 즉 복귀 번지가 대피된 " 직후"에 말이다(복귀 번지가 대피된 이후에도 호출 규칙에 따른 추가적인 대피가 계속해서 이어지므로 유의할 것). <그림 1-1> 근거리 호출시 스택의 내용 --------------------------------------------------------------------- 상위 번지 대피 순서 | | SP + 8: 0x5566 -+- 세번째 실매개변수 | | SP + 6: 0x7788 -+ | | SP + 4: 0x3344 --- 두번째 실매개변수 | | SP + 2: 0x1122 --- 첫번째 실매개변수 | | SP + 0: 복귀 번지(2바이트) 하위 번지 --------------------------------------------------------------------- <그림 1-2> 실제 스택의 상황(바이트 단위의 구조) --------------------------------------------------------------------- SP SP+2 SP+4 SP+6 SP+8 +----------+---+---+---+---+---+---+---+---+ | 복귀번지 | 22| 11| 44| 33| 88| 77| 66| 55| +----------+---+---+---+---+---+---+---+---+ --하위 번지 상위 번지-- --------------------------------------------------------------------- <그림 1-3> 실제 스택의 상황(워드 단위의 구조) --------------------------------------------------------------------- SP 0x55667788 +-------------+ +----------+-------+-------+-------+-------+ | 복귀번지 | 0x1122| 0x3344| 0x7788| 0x5566| +----------+-------+-------+-------+-------+ --하위 번지 상위 번지-- --------------------------------------------------------------------- <그림 2> 원거리/거대 호출시 스택의 내용 --------------------------------------------------------------------- 상위 번지 대피 순서 | | SP + 10: 0x5566 -+- 세번째 실매개변수 | | SP + 8: 0x7788 -+ | | SP + 6: 0x3344 --- 두번째 실매개변수 | | SP + 4: 0x1122 --- 첫번째 실매개변수 | | SP + 0: 복귀 번지(4바이트) 하위 번지 --------------------------------------------------------------------- 여기서 주의할 점은 첫째, 스택은 상위 번지쪽에서 하위 번지쪽으로 성장(SP가 감소)한다는 것이고 둘째, 8086계 CPU인 탓에 2바이트 이상의 크기를 가지는 데이타는 역워드(reverse word) 방식에 의해 항상 하위 바 이트부터 메모리에 차례대로 저장된다는 점이다. 따라서 4바이트 크기의 실매개변수인 0x55667788은 <그림 1-2>에서와 같이 0x88, 0x77, 0x66, 0x5 5의 순으로 메모리에 저장되니 착오없기 바란다. 자, 이제 C 호출 관행에서 또 하나의 중요한 사실을 설명하겠다. 그것 은 바로 "피호출 함수는 스택에 대피되어 있는 실매개변수의 개수를 전혀 알 수가 없다"는 점이다. 즉 원칙적으로 불가능하다. 대신에 피호출 함수의 입장에서는 "필요한 만큼의 실매개변수가 대피 되어 있다"고 가정할 수밖에 없다. 바꿔 말하면 실매개변수가 형식매개변 수의 개수보다 모자라거나 남아돌더라도 피호출 함수는 딱 맞는 개수만큼 이 있다는 가정하에서 모든 일을 처리한다. 이는 C 호출 관행의 경우 피호출 함수가 아닌 호출 함수 쪽에서 SP의 복구를 담당하기 때문에 파생되는 결과이다. 즉 스택에 대피되어 있는 실 매개변수들만큼의 복구(pop)를 호출 함수 쪽에서 담당한다. 다음 <리스트 2>의 맨 마지막 행에 있는 add sp,8 명령에 주목하기 바란다. <리스트 2> funca를 호출하는 어셈블리 코드 --------------------------------------------------------------------- mov dx,21862 --- 0x5566 mov ax,30600 --- 0x7788 push dx --+------- 마지막 실매개변수를 대피 push ax --+ mov ax,13124 --- 0x3344 push ax ---------- 두번째를 대피 mov ax,4386 --- 0x1122 push ax ---------- 첫번째를 대피 call near ptr _funca add sp,8 --- pop을 4번 행한 것과 같은 효과를 가져온다. --------------------------------------------------------------------- <리스트 2>를 보면 스택의 복구를 호출 함수 쪽(main 함수)에서 담당 한다는 것을 눈으로 확인할 수 있을 것이다. 말을 바꾸면 스택의 복구를 피호출 함수 쪽에서 행하면 절대로 안 된다고도 할 수 있다. 파스칼에서 어셈블리 링크를 해본 독자는 헷갈리지 않도록 특히 조심해야 한다. 즉 re t 명령에 숫자를 지정하면 절대로 안 된다. 참고로 스택을 복구할 때 pop 명령을 4번 쓰는 대신 add sp,8을 쓴 것 은 처리 속도상의 이점 때문이다. <리스트 1>에서 add sp,4 대신에 pop 명 령을 두 번 쓴 것도 같은 이유에서다. <표 1> C 호출 관행과 파스칼 호출 관행의 차이점 -----------------+------------------+-------------------- | C 호출 관행 | 파스칼 호출 관행 -----------------+------------------+-------------------- 매개변수 | 오른쪽에서 왼쪽 | 왼쪽에서 오른쪽 전달 순서 | (마지막부터) | (첫번째부터) | | 스택의 복구 | 호출 함수가 담당 | 피호출 함수가 담당 | | 매개변수의 개수 | 가변적일 수 있음 | 항상 고정적 -----------------+------------------+-------------------- --------------------------------------------------------------------- 8 반환값(return value)의 처리 --------------------------------------------------------------------- 피호출 함수가 일을 마치고 복귀할 때 반환값은 과연 어떠한 방식으로 자신을 호출한 함수에 되돌려 줄까? 그것은 아래와 같은 규칙에 의한다. --------------------------------------------------------------------- [1] 2바이트 크기 이하의 데이터형: AX에 저장한다. char, unsigned char, int, unsigned, enum, 근거리 포인터 등 [2] 4바이트 크기의 데이터형: DX:AX에 저장한다. (DX에 상위 2바이트를, AX에 하위 2바이트를) long, unsigned long, 원거리 포인터, 거대 포인터 등 [3] 부동형: 80x87의 TOS 레지스터, 즉 ST(0)에 저장한다. 단, 80x87을 에뮬레이트하는 경우 에뮬레이터의 TOS 레지스터에 저장한다. float, double, long double 등 [4] 구조체/공용체를 통채로 리턴하는 경우: 따로 전용으로 마련된 정적 데이터 영역에 결과를 저장한 다음 그 영역을 가리키는 포인터를 AX 또는 DX:AX에 넣어 되돌여 준다. --------------------------------------------------------------------- 대개의 경우 어셈블리와의 링크에서 주로 쓰이는 것은 아무래도 [1]번 또는 [2]번 방식이며, <예제 2>에서는 [1]번 방식을 확인할 수 있다. --------------------------------------------------------------------- 9 함수명에 덧붙는 밑줄문자의 의미 --------------------------------------------------------------------- 지금까지의 예제들을 보면 C 원시 코드의 함수명에는 안붙던 밑줄문 자가 어셈블리 코드의 함수명 앞에 덧붙여져 있는 것을 확인할 수 있을 것 이다. 예를 들어 main 함수의 어셈블리 코드에는 그 함수명이 _main으로 되어 있다. 사실 터보 C에서는 함수명이 어셈블리 코드로 컴파일될 때에 항상 그 앞에 밑줄문자가 덧붙여지도록 되어 있다. 그 이유는 볼랜드에서 공식적으 로 발표한 바 없으나, 추측컨대 터보 C의 내부 루틴이 직접적으로 호출되 는 것을 막기 위한 것으로 보인다. objxref.exe 유틸리티를 써서 터보 C 표준 라이브러리를 뒤적거려 보 면 대소문자가 마구 섞여 있는 괴상한 이름의 함수(실제로는 정식 함수도 아님)들이 많이 보이는데 이들은 대부분 선두에 밑줄문자를 가지고 있지 않다. 그것은 속도/크기 문제로 인해 C 호출 관행을 지키지 않은 일종의 어셈블리 서브루틴이기 때문이다. 따라서 이들을 C쪽에서 직접 호출하면 프로그램이 폭주하게 되므로 그러지 못하도록 모든 C 함수명에는 자동적으 로 선두에 밑줄문자가 덧붙도록 한 것 같다. 물론 컴파일러 옵션을 조정하면 밑줄문자를 제거할 수도 있지만, 그것 은 터보 파스칼과 링크할 때에나 필요한 조치이므로 자세한 설명은 생략하 겠다. --------------------------------------------------------------------- 10 소형 모델에서의 메모리 지도 --------------------------------------------------------------------- 지난 달에 소개했던 메모리 지도 예제에 대한 설명을 계속하자면 다음 과 같다. * 변수 설명(소형 모델에 해당하는 내용임!!) _heaplen: 근거리 힙의 바이트 크기를 나타낸다. 0의 값을 가지면 데이 터 세그먼트의 크기가 정확히 64k바이트가 되도록 근거리 힙 의 크기가 자동으로 결정된다. 따라서 근거리 힙의 최소 크기 는 1바이트가 된다. _stklen: 스택 영역의 바이트 크기를 나타낸다. 내정치는 4k바이트(409 6)이다. 그러나 이 변수가 스택의 크기를 4k바이트로 제한하 지는 못한다. 예를 들어 4k바이트가 넘는 자동배열을 정의해 도 실행시 에러가 나지 않는다. 다만 _heaplen과 함께 데이터 세그먼트의 크기를 결정하는 데 쓰인다. _psp: PSP의 세그먼트값을 가진다. PSP에 관한 설명은 지면상 생략 하겠다. 다만 옵셋 0x0002의 위치에 메모리 최상단의 세그먼 트값(640k 시스템에서는 0xa000)이 저장되어 있다는 것만 알 아 두면 프로그램을 이해하는 데에는 별 지장이 없을 것이다. __heapbase: 근거리 힙의 최하위 번지(즉 베이스)를 가리키는 포인터이다. 말을 바꾸면 정적 데이터 영역 직후를 가리키는 포인터라고도 할 수 있다. __heaptop: 근거리 힙의 현재 최상단을 가리키는 포인터이다. 프로그램 실행 직후에는 동적으로 근거리 힙이 할당된 것이 하나도 없을 터이므로 __heapbase와 동일한 값을 갖는다. _heapbase: 원거리 힙의 최하단을 가리키는 원거리 포인터이다. 원거리 힙은 항상 세그먼트 경계에서 시작하며, 또한 _heapbase는 정 규화되어 있으므로 그 옵셋(하위 2바이트)은 항상 0x0000이 다. _heaptop: 원거리 힙의 최상단을 가리키는 원거리 포인터이다. 주의할 사항은 __heaptop과는 달리 _heaptop은 메모리의 최상단을 가 리킨다는 점이다. 따라서 640k바이트 시스템에서는 항항 A00 0:0000의 값을 갖게 된다. 참고로 __heapbase, __heaptop, _hearbase, _heaptop 등은 터보 C 매 뉴얼에 설명되어 있지 않으며, _heaplen, _stklen, _psp는 Turbo C Refere nce Guide의 28, 30, 29쪽에 상세히 설명되어 있다. 또한 매뉴얼에 설명되어 있지는 않지만, _heaplen과 _stklen 변수에 값을 지정할 때에는 <예제 3>처럼 반드시 외부변수의 초기화 형식이어야 하는데 주의하기 바란다. 프로그램 실행 후 어떤 값을 대입하는 것은 아무 의미도 없다. 그것은 그 변수들을 참조하는 루틴이 main 함수가 호출되기 이전의 기동 코드(startup code)이기 때문이다. * 소형 데이터 모델에서 데이터 세그먼트의 크기를 결정하는 공식 void *ptr; unsigned DSsize; --- 패러그래프 단위의 크기 if (_heaplen == 0) DSsize = 0x1000; --- 환산하면 65536바이트 else { ptr = (char *)__heapbase + _stklen + _heaplen; DSsize = ((unsigned)ptr >> 4) + 1; } 참고: 이 공식은 기동 코드 c0.asm을 분석해서 얻은 것임. * 램상주 프로그램(초소형 또는 소형 모델)에서 상주 크기(keep size)를 구하는 공식 2가지 +- unsigned keepsize; --- 상주 크기 +- unsigned CSsize; --- 코드 세그먼트의 크기 | +----------------------- 패러그래프 단위 keepsize = FP_SEG(_heapbase) - _psp; --- 가장 간단한 공식 (모든 모델에서 통용) 또는(초소형/소형 모델에서) CSsize = _DS - _CS; --- 초소형 모델에서는 항상 0 keepsize = 0x10 + CSsize +DSsize; | +-- PSP의 크기 위의 상주 크기는 램상주 프로그램에서 아래와 같이 쓰인다. keep(0, keepsize); 만약 _heaplen이 0(내정치)이라면 데이터 세그먼트의 크기가 65536바 이트로 결정되므로 구태여 복잡한 공식 쓸 필요 없이 간단하게 keep(0, 0x 1000)이라고 해도 된다. <예제 3> 소형 메모리 모델의 메모리 지도 --------------------------------------------------------------------- /* File MEMMODEL.C */ #include #include #include #pragma warn -par /* off warning */ unsigned _heaplen = 0x0001; /* minimum value */ /* if _heaplen == 0 or _heaplen is too large, this program will output wrong results */ unsigned _stklen = 0x0250; /* minimum value is 0x0200 when the software emulation for the floating point operation */ extern unsigned _psp; /* program segment prefix */ /* declared in dos.h */ extern void *__heapbase; /* a pointer to the near heap base */ extern void *__heaptop; extern void far *_heapbase; /* a pointer to the far heap base */ extern void far *_heaptop; void main(int argc, char *argv[], char **env) { unsigned CSsize; /* code segment size in paragraph(small model) */ unsigned DSsize; /* data segment size in paragraph */ unsigned StartingSP; /* initial value of SP */ unsigned farheap; /* segment of the far heap base pointer */ unsigned keepsize; /* calculated keep size in paragraph, i.e. total program size */ void *ptr; void far *topofmem; /* far pointer to the top of the memory */ CSsize = _DS - _CS; /* when small model */ ptr = (char *)__heapbase + _stklen + _heaplen; DSsize = ((unsigned)ptr >> 4) + 1; StartingSP = DSsize << 4; farheap = FP_SEG(_heapbase); /* get segment of the _heapbase */ keepsize = farheap - _psp; /* print the structure of the small memory model */ printf("Porgram segment prefix == %#06x\n", _psp); printf("Code segment == %#06x\n", _CS); printf("Data segment == %#06x\n", _DS); printf("Stack segment == %#06x\n", _SS); printf("Extra segment == %#06x\n", _ES); printf("Offset of static data area to DS == 0x0000\n"); printf("Offset of near heap base to DS == %#06x\n", __heapbase); printf("Offset of near heap top to DS == %#06x\n", __heaptop); printf("Current stack pointer == %#06x\n", _SP); /* print the initial value of SP calculated by three different methods */ printf("Initial value of SP == %#06x\n", StartingSP); printf(" == %#06x(other method)\n", (farheap - _DS) << 4); /* print the map of the far heap */ topofmem = MK_FP(*(unsigned far *)MK_FP(_psp, 0x0002), 0x0000); printf("Far heap base == %Fp\n", _heapbase); printf("Far heap top == %Fp\n", _heaptop); printf("Top of memory == %Fp\n\n", topofmem); /* print sizes */ printf("CS size == %#06x paragraph\n", CSsize); printf("DS size == %#06x paragraph(including stack)\n", DSsize); printf("Keep size == %#06x paragraph\n", keepsize); printf(" == %#06x(other method)\n", 0x10 + CSsize + DSsize); printf("Free space in near heap == %#06x byte(including stack area)\n", _SP - (unsigned)__heaptop + 1); printf("Free space in far heap == %ld byte\n", (unsigned long)(FP_SEG(_heaptop) - FP_SEG(_heapbase)) << 4); printf(" == %ld byte(other method)\n", (unsigned long)(FP_SEG(topofmem) - FP_SEG(_heapbase)) << 4); /* for a TSR program "keep(0, keepsize);" is required before quit program */ } --------------------------------------------------------------------- 실행 결과 (터보 C 2.0에서 컴파일하여 도스 프롬프트상에서 실행) Porgram segment prefix == 0x16c2 Code segment == 0x16d2 Data segment == 0x1822 Stack segment == 0x1822 Extra segment == 0x1822 Offset of static data area to DS == 0x0000 Offset of near heap base to DS == 0x076e Offset of near heap top to DS == 0x076e Current stack pointer == 0x098a Initial value of SP == 0x09c0 == 0x09c0(other method) Far heap base == 18BE:0000 Far heap top == A000:0000 Top of memory == A000:0000 CS size == 0x0150 paragraph DS size == 0x009c paragraph(including stack) Keep size == 0x01fc paragraph == 0x01fc(other method) Free space in near heap == 0x021d byte(including stack area) Free space in far heap == 554016 byte == 554016 byte(other method) --------------------------------------------------------------------- --------------------------------------------------------------------- 11 다음에는 --------------------------------------------------------------------- 별로 한 얘기도 없는데 벌써 이번 글의 끝맺음을 할 때가 된 것 같다. 한꺼번에 너무 많은 얘기를 하면 지루할 것 같아 이쯤에서 일단락 지었다. 다음 달에는 이번 강좌의 핵심인 C와 어셈블리 루틴의 접속(interface)에 대하여 본격적으로 설명을 해 나가겠다. <제3회 끝>  #52 임인건 (turbo28 ) [강좌] C깊은곳4-1: 어셈블리 코드 접속 I 05/06 00:16 491 line 마이크로소프트웨어 게재: 1990.8 HWP/TXT 변환: 1993.5.5 >>> 터보 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. 어셈블러와 링커의 사용법 지면 사정상 후반부에 대한 얘기는 다음 회로 미뤄야 할 것 같다. 다 음 달이 다가오기 전에 이번 회의 설명을 충분히 소화해 내기를 바라며 이 만 줄일까 한다. <제4회 끝>  #54 임인건 (turbo28 ) [강좌] C깊은곳5-1: 어셈블리 코드 접속 II 05/06 00:19 399 line 마이크로소프트웨어 게재: 1990.9 HWP/TXT 변환: 1993.5.5 >>> 터보 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 등의 지시자를 쓰지 않게 될 것이다. <제5회 끝>