제목 : - 640 KB 극복 안녕하세요 허르미입니다. 오늘은 Virtual Memory 에 대 한 강좌를 계속하도록 하겠읍니다. Virtual Memory Library 는 크게 네부분으로 구성되어 있읍니다. 즉 Conventional Memory 관 리부분,EMM 관리,HardDisk 관리 부분,그리고 이들을 묶어서 Management 해주는 부분입니다. 사용자는 지금 확보되어 운용되 는 메모리가 EMM 인지,HardDisk 인지,Conventional Memory 인지 를 생각할 필요가 없읍니다. 전체적으로 관리해주는 루틴이 적당 히 선택해줍니다. 우리가 char *buff 를 선언해서 char 형의 포 인터를 다루듯이 Virtual Memory 라이브러리에서는 LogicHandle 이라는 것을 두어서 관리하게 됩니다. 즉 일반메모리에 확보한 포인터인지,페이징과 매핑이 필요한 EMM 에 할당된 메모리인지, 하드디스크에 Swapping 하는 화일인지는 내부에서 처리해주므로 사용자가 hgVMalloc 함수로 확보한 영역은 모두 LogicHandle 로 표시됩니다. 이 LogicHandle 번호는 사용자가 신경쓸 필요가 없 읍니다. 내부에서 일괄적으로 처리하기 위한 방법일 뿐입니다. 예를 들어봅시다. VMEM *p; <- VMEM 형의 포인터 선언. p=(VMEM *) hgVMalloc((unsigned)size); 하고 선언하면 p 는 VMEM 형의 포인터로 선언되게 됩니다. VMEM 은 헤더화일에서 다음과 같이 선언되어 있읍니다. typedef struct vmem { int logichandle; int type; } VMEM; 즉 각 VMEM * 형의 버퍼는 logichandle 과 type 을 가지고 있읍 니다. logichandle 은 그 Resource 에 관계없이 1 부터 붙여나가 는 일련번호와 같은 것입니다. type 은 #define CON 1 #define EMM 2 #define HARD 3 과 같이 정의되어 있읍니다. hgVMalloc 함수에서 해주는 일은 버 퍼를 실제로 확보하는 일이 아닙니다. logichandle 을 할당해주 고 type 에 따라서 적당히 초기화 처리를 해주는 것입니다. Virtual Memory System 을 간단하나마 구현하는 것은 그 효용에 비해 소스가 간단한 편입니다. 따라서 강좌내용에서 자세히 분석 해 볼만한 가치가 있다고 생각합니다. 현재 허르미 2.0 으로 버 전업중인데 VGA 의 Image 관리를 Virtual Memory 를 도입해서 해 내기 때문에 화면전체를 마구 저장/복귀하더라도 무리없이 실행 됩니다. EMM 이 있으면 그 영역을 모두쓰고,없으면 HardDisk 를 Swap 해서 원하는 결과를 얻어냅니다. 그럼 일단 전체적인 구성 을 살펴보도록 하겠읍니다. 1. 사용자는 VMEM * 형을 선언. 2. hgVMalloc 함수에 원하는 Size 를 넘겨준다. 3. hgVMalloc 함수에서는 먼저 Conventional Memory 를 Check 한다. 4. -> Conventional Memory 확보루틴 5. 4 에서 실패하면 -> EMM 확보루틴 6. 5 에서 실패하면 -> HardDisk 확보루틴 7. return NULL; 7 까지 갈 경우는 거의 없다고 봅니다. HardDisk 는 보통 MEGA 단위로 남겨놓으므로 HardDisk 까지도 Swap 이 불가능하기란 어 려운 일이기 때문입니다. 위의 간단한 흐름도는 실제 소스에서 다음과 같이 보여집니다. VMEM *hgVMalloc(unsigned size) { VMEM *p; p=hgVMallocCON(size); if (p!=NULL) return p; p=hgVMallocEMM(size); if (p!=NULL) return p; p=hgVMallocHARD(size); if (p!=NULL) return p; return NULL; } hgVMallocCON 이라는 Sub Function 은 일반메모리에 확보해주는 역할을 합니다. hgVMallocEMM 은 EMM 에 확보,hgVMallocHARD 는 HardDisk 에 확보하는 역할을 합니다. 확보에 실패하면 각각은 NULL 을 리턴합니다. 확보가 되면 VMEM 형의 포인터를 리턴해주 는데 이 포인터에는 LogicHandle 의 값과 Device Type 의 값을 가지고 있읍니다. LogicHandle 은 그 버퍼가 가지는 고유번호로 써 각 Sub Function 에서 쓰이는 Table 의 기록자료로 이용됩니 다. Device Type 은 위에서 언급했듯이 Resource 의 종류를 가리 키는 것이고요. 허르미 V.System 의 운용핵심은 Global Buffer 의 사용과 Swapping 에 있읍니다. V.System 에서 데이터를 관리 하는 방식은 조금 특수합니다. 사용자는 64 KB 로 확보되어 있는 Global Buffer 에서 작업을 해야 합니다. 즉 VGA 의 이미지를 저 장한다고 할때 원래는 아래와 같이 했었읍니다. char *buff; buff=(char *) ~~ -> 확보과정 hgGetImage(x1,y1,x2,y2,buff); <- 확보 이렇게 되면 buff 라는 영역에 VGA 의 이미지가 들어가게 되죠. 만일 이미지를 하나 더 잡으면 어떻게 될까요.. 또 하나의 버퍼 가 필요하겠죠.. 즉 Conventional Memory 만을 계속 쓰게 됩니 다. 이것을 극복하기 위해서 V.System 에서는 vgbuff 라는 전역 버퍼를 미리 64 KB 만큼 (한 버퍼가 취할 수 있는 최대크기임.) 확보해 둡니다. 이 전역버퍼에 VGA 의 이미지를 저장하는 것입니 다. 즉 다음과 같이 됩니다. hgGetImage(x1,y1,x2,y2,vgbuff); 이 버퍼를 가지고 다시 hgPutImage 등에 이용할 수 있는 것은 두 말할 나위가 없읍니다. 그렇다면 이미지를 하나 더 잡는다면 역 시 작업 영역은 vgbuff 이므로 전에 잡았던 이미지가 파괴되게 되겠죠. 그러므로 그 전에 적당한 영역으로 Swapping 을 해주는 것입니다. Swapping 을 하면 V.System 이 적당한 곳으로 vgbuff 의 내용을 Swapping 하게 되고,그 후에는 다시 hgGetImage 로 vgbuff 에 이미지 2 를 저장합니다. 이들은 다시 SwappingIn,즉 vgbuff 로 읽어들여질 수 있는데 필요할때 적당한 것을 vgbuff 로 읽어 들인다면 이미지의 수에 관계없이 Conventional Memory 에서는 vgbuff 만큼,즉 항상 64 KB 만큼만을 쓰게 되며 이미지는 모두 저장할 수 있게 됩니다. 즉 두개의 이미지를 저장하려면 다 음과 같이 되겠죠. 두개의 이미지중 어느것을 불러올지를 정하고 어디에 저장했는지 등을 기억하기 위해서는 버퍼관리를 위한 핸 들을 정할 필요가 있읍니다. 자꾸만 말이 복잡해 지는데 아래의 예제를 봅시다. VMEM *p1,*p2; p1=(VMEM *)hgVMalloc((unsigned)size1); p2=(VMEM *)hgVMalloc((unsigned)size2); hgGetImage(x1,y1,x2,y2,vgbuff); hgVSaveBuff(p1); hgGetImage(x1,y1,x2,y2,vgbuff); hgVSaveBuff(p2); 위의 예제의 첫줄은 LogicHandle,DeviceType 을 저장하기 위한 핸들의 포인터를 2 개 선언합니다. (p1,p2) 그아래 두 문장은 p1,p2 를 적당한 곳에 Allocate 하기 위해서 LogicHandle , DeviceType 을 V.System 으로부터 할당받습니다. vgbuff 는 초기 화 루틴에서 이미 64 KB 로 확보되어 있는 버퍼이고 hgGetImage 로 그 버퍼에 화면 이미지를 담아 옵니다. hgVSaveBuff(p1) 명령 에 의해서 p1 에 할당된 영역에 vgbuff 의 내용을 Swapping 합니 다. 즉 첫번째 hgGetImage 로 잡은 이미지를 p1 에 적당히 할당 된 곳에 저장하는 셈이죠. 그다음에 다시 hgGetImage 함수로 vgbuff 에 이미지를 담아옵니다. 전에 담겨있던 vgbuff 의 내용 은 파괴되었지만 이미 저장해 두었으므로 관계는 없읍니다. 다시 hgVSaveBuff(p2) 함수는 새로담아온 vgbuff 의 내용을 p2 에 할 당된 버퍼로 Swapping 합니다. 즉 vgbuff 의 내용을 p2 에 할당 된 기억장소로 옮겨주는 것입니다. 그렇다면 이제 메모리의 내용 은 어떻게 되는 것일까요. vgbuff 는 여전히 64 KB 짜리 버퍼로 남아있읍니다. 하지만 화면 이미지 2 개를 잡은 영역은 V.System 이 할당해준 메모리에 저장되어 있는 것이고 그들은 각각 고유한 LogicHandle 번호를 가지면서 p1,p2 로 지칭할 수 있는 것이죠. 그렇다면 이제 다시 hgPutImage 로 복귀하는 부분을 작성해 봅시 다. 이를 위해선 일단 p2 에 할당된 부분을 vgbuff 로 가져온다 음에 vgbuff 의 내용을 화면에 복귀해주면 됩니다. 즉 hgVSetBuff(p2); hgPutImage(x1,y1,x2,y2,vgbuff); 그다음에 다시 p1 에 할당된 부분을 vgbuff 로 가져온다음에 vgbuff 의 내용을 화면에 복귀합니다. hgVSetBuff(p1); hgPutImage(x1,y1,x2,y2,vgbuff); 결국 vgbuff 라는 중간 매개 버퍼를 통해서 우리는 작업을 하고, 필요할때마다 Swapping 함으로써 보다 많은 데이터를 다룰 수 있 게 되는 것입니다. 이러한 방식이 Virtual Memory System 을 구 현하는 데 있어 유일한 방법은 결코 아닙니다. 그러나 전역버퍼 방식을 사용하게 되면 몇가지 장점과 단점을 함께 가지게 되는데 간단히 살펴보겠읍니다. 우선 단점을 살펴보면 전역버퍼에 필요한 64 KB 만큼의 버퍼를 Conventional Memory 에 항상 확보해 두어야 한다는 점이 있읍니 다. 아무리 매개 버퍼라고는 하지만 64 KB 의 양은 그리 적은 것 이 아니므로 프로그래머에게 부담이 되는 것은 사실입니다. 또하 나의 단점은 적절한 시기에 Swapping 을 해야 하는데 이 시기를 결정하기가 쉽지 않다는 데 있읍니다. 사실 Swapping 의 수는 가 능한한 줄여야 Virtual Memory Access 가 빨라질 것입니다. 위에 서 hgVSetBuff,hgVSaveBuff 함수는 만일 대상을 HardDisk 로 한 다면 느려질 것이므로 Swapping 을 자주 할 수록 프로그램의 효 율이 떨어지는 것은 당연합니다. 가장 큰 단점은 전역버퍼가 한 개이므로 프로그램이 어려워 진다는 데 있읍니다. 예를 들어 두 가지의 데이터를 V.System 을 이용해서 저장한다고 합시다. 두가 지의 데이터를 저장하기 위해서는 일단 하나를 읽어서 저장하고, 또 하나를 읽어서 저장해야 합니다. 즉 순서대로 해야 한다는 것 이죠. 두개를 다 읽어서 저장할 수 있는 방법이 없읍니다. 왜냐 하면 vgbuff 는 하나이기 때문이죠. 그럼 장점을 살펴보겠읍니 다. 간단한 방법,즉 Swapping 이라는 방법을 통해서 수메가에 이 르는 방대한 영역을 쓸 수 있게 됩니다. 또한 vgbuff 는 64 KB 짜리 버퍼이므로 단일 버퍼를 대상으로 프로그램을 하게 되어 일 관성있고 융통성있는 프로그램을 할 수 있게 된다는 점이 있읍니 다. 또한 V.System 의 구조가 간단해 진다는 것도 매우 큰 잇점 입니다. 단점이 많이 보이지만 이들을 해결할 수 있는 방법이 없는 것은 아닙니다. 우선 첫번째,즉 64 KB 의 전역버퍼에 관한 문제는 그 리 걱정할 것이 없읍니다. 오히려 64 KB 만큼만을 Conventional Memory 를 쓰고 나머지는 적당한 영역을 Allocate 하므로 큰 프 로그램을 작성할때는 오히려 메모리를 절약하는 셈이 됩니다. 또 한 Swapping 시기문제는 이 V.System 을 이용하는 방법적인 문제 이므로 이 Virtual Library 강좌가 끝날무렵 hr.exe (물보라 한 글 리더) 을 디자인 하면서 얻은 것을 소개하고자 합니다. 마지 막으로 두개의 데이터를 한번에 다룰 수 없다는 것인데 이것은 Swapping 을 적절히 이용하면 해결 할 수 있는 문제입니다. 64 KB 의 vgbuff 를 Swapping 하는데는 HardDisk 가 아닌 다음에야 매우 짧은 시간에 이뤄지므로 속도는 크게 생각할 필요가 없읍니 다. 또한 제 테스트로는 HardDisk 에서도 만족스럽게 동작하는 것을 확인했읍니다. 허르미 한글 라이브러리 2.0 에서는 화면 이 미지 관리를 위해서 Virtual Library 를 도입하였읍니다. 이경우 이미지 저장함수의 내부에서는 언제나 적당한 Virtual Buffer 를 확보하여 할당하고 Swapping 해둡니다. 이미지 복귀함수에서는 다시 vgbuff 로 저장내용을 옮긴후 화면에 표시하게 되므로 Swapping 을 프로그래머가 생각하지 않아도 되게 되어 있읍니다. hr.exe 와 같은 프로그램은 이미지 저장만이 아니라 출력 Text 도 Virtual Memory 에 올려놓는 방법을 제시하고 있읍니다. 역시 자세한 응용법은 Virtual 의 강좌가 끝날무렵 다시 제시하도록 하겠읍니다. 그럼 다음 강좌 부터는 Conventional,HardDisk,Emm 의 순으로 SubFunction 을 살펴보게 될텐데 이를 위해서 기본적 인 사항을 조금 본후에 이번 강좌를 끝내도록 하겠읍니다. 우선 Segment,Offset 의 개념입니다. 80x86 계열의 CPU 들은 적은 bit 수의 주소 레지스터로 보다 많 은 영역을 Addressing 하기 위해서 Segment,Offset 이라는 개념 을 도입했읍니다. 1 MB 까지의 메모리 공간은 이 Segment,Offset 에 의해서 어느곳이든 지적이 가능합니다. 즉 Segment,Offset 만 있으면 어느 한곳의 주소를 가리킬 수 있다는 것이죠. 보통 Far pointer 라고 말하는 것은 Segment 와 Offset 값을 가지고 있어 서 메모리의 어느곳이나 가리킬 수 있읍니다. 하지만 Near Pointer 라는 것은 Offset 값만을 가진 것으로써 Segment 는 특 정 Segment Register 의 값을 참조하여 Segment:Offset 의 주소 를 구하는 방식으로써 Segment 값이 바뀜에 따라 다른 주소를 가 리킬 수도 있다는데 주의해야 합니다. 하지만 속도는 Far Pointer 에 비해서 빠릅니다. Segment 와 Offset 은 다음과 같은 관계를 지니고 있읍니다. 즉 1 MB 를 표현하기 위해서는 20 bit 가 필요한데.. 이중 앞의 16 bit 를 Segment Register 가 가리키 고,뒤의 16 bit 를 Offset Register 가 가리키게 됩니다. 즉 A000 <- Segment + 0100 <- Offset ---------- A0100 처럼 되어서 A000:0100 (Segment:OFfset 으로 보통 씀) 은 A0100 이라는 20 bit 주소를 가리키게 되는 셈이 됩니다. 2^20 = 1 MB 이므로 이러한 방식으로 최대 주소 지정 가능 범위는 1 MB 인 셈 입니다. V.System 에서는 Conventional Memory 를 다루는데 있어 서 이 Segment,Offset 를 저장함으로써 버퍼의 위치를 알아내는 데 사용하고 있읍니다. 자세한 것은 다음 강좌편에 나오겠지만 이 Segment,Offset 이 20 비트의 주소중에서 임의의 위치를 가리 키는데 사용한다는 것을 알아두세요. 그다음에.. EMM 을 사용하 기 위해서는 config.sys 에 emm386.exe 를 넣어두어야 합니다. (80386 의 경우) 뒤에는 KB 로 Size 값이 옵니다. 즉 device=emm386.exe 1024 하면 1024 KB , 즉 1 메가를 emm 으로 쓰겠다는 선언이 되겠죠. 일단 이렇게 선언해 두면 도스 커맨드에서 emm386 OFF 하면 emm 을 일시적으로 Unable 하게 하며 emm386 ON 하면 다시 Able 하게 해줍니다. 286 의 경우에는 그에 맞는 적당 한 LIM 4.0 규격의 EMM driver 를 쓰시면 됩니다. 마지막으로.. HardDisk 에서는 보통 DiskCache 를 씁니다. 이 DiskCache 는 효 율이 좋은것을 쓰면 HardDisk Swapping 속도를 향상시켜줍니다. 메모리가 충분하지 않은 경우 EMM 과 DiskCache 영역을 적당히 잡아주어야 겠죠. V.System 에서는 Borland C++ 2.0 의 built-in Function 인 fread 와 fwrite 를 써서 버퍼를 하드디스크에 일괄 전송/읽기를 하고 있읍니다. 이 함수는 블럭단위로 전송을 하므 로 빠르게 동작하며 DiskCache 로 효율을 높일 수 있읍니다. 물 론 EMM 이나 Conventional 보다는 느리겠지만 V.System 의 테스 트 과정에서 HardDisk 도 상당히 쓸만한 기억공간이 될 수 있다 는 것을 느꼈읍니다. 사실 Memory 에서는 1,2 메가가 큰 양이지 만 하드디스크에서는 작은 양이잖아요 ? 하드디스크를 사용해서 Swapping 한다는 것도 적당한 때 쓰면 그 효용성은 대단한 것입 니다. V.System 의 최대 장점이 Resource 를 자동선택,또는 한가 지 지정선택등이 가능하기 때문에 적절히 Resource 를 사용할 수 있다는 점입니다. 그럼. 무척 개요에 관한 부분이 길어졌는데.. 다음 강좌에는 Conventional Memory 관리부분을 설게해 보도록 하겠읍니다. 그럼. 허르미!