OS를 만들면서 아직 메모리 관리도 안되고, 스케쥴러도 되지 않는 OS라고 부르기엔 참 민망한 OS이지만 현재 개발은 계속되고 있는 중입니다. 저번주 토욜날 할머니께서 돌아가시는 바람에 부랴부랴 내려가서 3일장을 치르고 오느라 기능을 많이 추가하지는 못했군요. 그 전에도 면접에 대한 준비도 하고 실제 면접도 치르느라 시간이 훌쩍 지나갔습니다^^.
예전에 올라왔던 스캔코드를 찍었던 스샷과는 다르게 키보드 처리도 어느정도 된 상태의 스크린샷입니다. 모처에 면접을 볼때는 help, mem, size의 단 3개의 명령어만 존재했는데, 현재 메모리관리자를 넣어보려고 하니 제가 생각한 구조에서는 미리 MP Configuration Table을 어느정도 분석하여 코어 개수에 대한 정보가 필요하더군요. 그래서 Process Control Block 도 지정하고 Bootstrap Core 인덱스도 구하고 하는 등의 작업을 추가 했습니다. 대충 생각한 메모리관리자의 구조가 아래와 같습니다.
3. 프로세스에서 메모리 할당 요청이 들어오면 MemoryAllocator에서 남아있는 여유분의 블럭이 있는지 조사하고 서비스가능한 블럭이 있을경우 BuddyBlock 작업을 수행하여 할당을 한다. 만약 블럭이 없을 경우 PageAllocator에 페이지 할당을 요청한다.
4. PageAllocator에서는 각 Page에 대해서 소유 프로세스를 관리하며, 각각의 페이지 사이즈를 관리한다. 페이지의 할당 요청이 들어왔을 때, 서비스 가능한 페이지가 있다면 해당 페이지를 할당해주고, 아닐 경우 NULL을 리턴한다.
5. 페이지가 할당 요청이 되었을 때에는 MemoryAllocator에 요청된 공간만큼 할당을 시켜준 다음 남은 블럭은 MemoryAllocator에서 자체적으로 다시 관리한다.
6. 해제의 경우 MemoryAllocator에서 남은 블록을 해제 하며 Merging을 수행하여 해당 블럭이 PageAllocator에서 할당하는 기본 페이지 사이즈가 되면 해당 PageAllocator에 페이지 소유를 이양하고 빈 페이지로 설정한다.
아직 다른 OS에서의 메모리 관리를 자세하게 살펴보지를 않은 상태라 나름대로 고민을 하여 구성을 해보았는데 스스로는 꽤나 괜찮다고 생각을 하지만 알고보면 평범할것 같기도 하여 열심히 구현만 하고 있습니다. 이제 메모리 관리자가 제대로 구현되고 나면 실제로 이제 구현되어야할 스케쥴러를 구현하여 멀티태스킹이 들어가게 되고 이 부분이 되고 나면 그래도 그럭저럭 OS라고 부를 수 있지 않을까 하는 생각이 조금씩 드네요^^;
다음에도 더 발전된 포스팅 거리를 들고 찾아뵙도록 하겠습니다. 다른 일이 생기지 말아야 빨리 작업이 될텐데 말이죠^^;
동방환상마작 포스팅 이후로 오랜 시간이 흐른 뒤의 포스팅입니다. 그 동안 병역특례의 기간도 끝을 보게 되었고, 한 달 여 정도 문서와 구글속에서 파묻혀 살았습니다. 사실 게임도 아주 약간 했다는 것을 숨길 수는 없겠습니다. 전체적으로 구상도가 정리되지 않는 문서를 보고 있으려니 아주 막막하더라구요^^. 그리하여 한 달 정도 여러가지 문서를 보고 다른 할 일도 처리하면서 시간을 보냈습니다. 아래의 것이 그 결과물 입니다(?)
처음에 보이는 깨지는 문자를 C 로 쓴 커널Entry 에서 보이도록 만들었는데 작동합니다. ㅜㅜ 사실 여태까지 한 번도 롱모드 쪽으로는 전환해본적이 없는데 일단은 성공을 했습니다. 그런데 아마.. 이제부터 시작일 것 같군요^^; IDT를 비롯해서 Memory Management 쪽도 만들어야 하고.. 할 일이 많을것 같습니다. 맨 처음에는 BIOS 인터럽트를 이용하여 부트로더에서 커널로더를 올렸고, 커널로더에서는 x64의 롱모드로 진입 후, CHS모드를 이용하여 데이터를 직접 1MB 영역에 올렸습니다. 그런 다음에 바로 점프를 한셈이구요. rep 를 붙여서 명령어를 돌리는데, 왜 계속 리부팅 되지 되지 하다가.. rcx 가 아니라 ecx 로 데이터를 준 것을 발견하고 삽질 중에 고쳐서 겨우 진입 했습니다. 이게 바로 삽질의 매력(?) 인가요 ㅜㅜ 일단 어쨌든.. 앞으로 할 것이 많이 남은 듯 하군요^^;
개인적으로 오늘 더욱 확실히 알고 싶어 컴퓨터에 대한 기초를 자세히 공부하고 있는 도중 x64에 대한 궁금함이 몇몇 부분에 대해서 드는 것이 있었습니다. 사실 x64 라는 것을 맨 처음 AMD(Advanced Micro Devices)의 K8 Hammer 시리즈에서 나올때 부터 관심을 가지고 있었던 터라, 754소켓 플랫폼인 뉴캐슬당시 그 쪽 방향으로 업그레이드 하게 되었고, XP x64를 나오기 기다려, 데몬(Daemon)또한 x64버젼이 나오길 기다렸던 기억이 생생합니다. 그 당시 인상적인 기억으로는 32비트 XP 에서 기본 계산기로 50000! 명령어를 내렸을 때, 20초 걸렸던 것이 64비트 XP에서는 50000!에 대한 경과시간이 10초 내외였던 것이 있었습니다. 그로인해 당시 엄청난 성능적 이득이 있을것이라 생각하였지만 실질적으로 여러가지 복합적인 이유로 인해 그다지 성능적 이득이 없었던 현상이 있긴 했습니다. 나름대로 64비트에 대한 선망을 가지며 많은 자료를 찾아보고 했으나 지금 생각해보니 기초에 대한 많은 부분을 조사하지 못하고 그냥 무작정 열망했었던 것이 아닌가 하는 생각이 갑지가 들어서 자료를 찾아보게 되었습니다. 64비트 프로그래밍을 하기 위해 가장 쉽게 접할 수 있는 IDE는 아무리 생각해도 VS.net 2005, VS.net 2008이라고 할 수 있습니다. 물론 다른 컴파일러도 64비트 플랫폼 설정을 할 수 있고, 컴파일을 진행할 수 있지만 자료를 쉽게 찾을 수 있다고 생각하기 때문에 VS를 선택했습니다. VS.net 을 설치할 때 마다 x64 Compiler를 체크하여 설치하긴 했지만 실제 개인적으로 사용하기 위해 개발했던 유틸을 제외하고는 개발하여 배포한적이 없었습니다. 그 만큼 x64에 대한 관심이 부족하지 않았나라고 생각합니다. 64비트 프로그래밍에 대한 염두에 두어야할 점을 생각하면 다음과 같은 점이 있더군요.
1. int, long은 결코 64비트 값이 아닌점
일반적으로 흔히 한 컴퓨터가 한 번에 처리할 수 있는 용량을 워드라고 부르고, 그로인해 보통 생각하는 int형 데이터가 64비트에서는 64비트라고 생각하기 쉽습니다( 하지만 Windows 32비트 환경에서는 32비트 데이터를 DWORD라고 합니다 ). 물론 저도 아무것도 모를때는 막연히 그렇지 않을까라고 생각했습니다. 하지만 자료를 찾아보니 값 자체는 32비트의 값을 지니게 되고, 포인터는 64비트 값을 가지게 되는 점이 다르더 군요. 실질적으로 C코드 의 종류를 예를 든다면 sizeof(int *)형태의 값이 일반적인 4가 아니라 8이 나온다는 점입니다. 64비트 값은 VS.net 에서는 __int64로써 사용할 수 있습니다. 32비트에서도 사용가능합니다. 성능상의 차이는 있겠죠.
2. 표준에 대한 자료형 크기가 다르다.
size_t, time_t, ptrdiff_t에 대해서 알고 계신가요? 저 같은 경우 STL에서 주로 사용하던 것인데 보통 생각할 때 32비트 머신에서 사용하였으므로 그 크기는 32비트 자료형으로 알고 있었습니다. 하지만 64비트에서는 64비트 자료형으로 사용이 된다는 점입니다. 보통 생각하셔도 당연한 얘기가 될 수 있을지도 모르겠습니다. 포인터 자체가 64비트 자료형을 띄게 되는데, 위치 차이인 ptrdiff_t가 64비트가 아니라면 연산자체의 문제가 발생할 수 있지 않을까요^^? 그런데 time_t에 대해서는 약간 의문점이 듭니다.
3. time_t에 대해선..
time_t 자료형에 대해선 굳이 깊히 생각할 일이 없어보입니다. VS.net 에서는 비트 플랫폼과 상관없이 2005 이상이냐 이전이냐에 따라서 자료형의 크기가 달라지더군요. 이 전에서는 32비트 값을 사용하였으나 2005 이상에서는 64비트 값을 사용하게 되었답니다. 이유는 32비트 값을 사용하게 되면 UTC 타임으로 2038년 1월 19일 이후의 시간을 표시할 수 없기 때문이라고 하네요. 예전 Y2K버그 였던 밀레니엄 버그로 한창 떠들석 했던 것을 생각하면 당연한 것으로 보입니다.
4. 기본 함수 Calling Convention은 __fastcall.
x86과 x64에 대한 레지스터 차이를 아실지 모르겠습니다. 기존 존재하던 EAX, EBX, ECX, EDX, ESP, EBP, ESI, EDI 이 32비트 크기에서 64비트 크기로 확장됨과 더불어 Rxx 로 시작하는 일반적인 레지스터 R9, R10, R11, R12, R13, R14, R15가 추가 되었습니다. XMM 레지스터도 8개가 추가적으로 확장되었죠. 그런데 이런 레지스터를 놀리는 짓은 성능에 많은 제약을 가하는 꼴이 아닐까요^^? 그래서 기본적으로 많은 레지스터를 생각하는 것으로 __fastcall이 기본이 되지 않았을까 생각합니다.
R11, R11등의 레지스터는 참조한 링크에서 다른 사용방법이 있으므로 참조를 해보세요^^. 기본적인 사용법만 적어봤습니다. 어셈블리어로 코드를 작성할 때 유용하겠네요.
6. 더이상의 Inline Assembly는 지원하지 않음
x86 C++ 프로그래밍을 할 당시는 __asm{} 과 같은 문법들로 inline assembly를 사용할 수 있었습니다. 그로인해 어셈블리 코드를 직접입력할 수 있었습니다. 그런데 x64에서는 지원을 하지 않는다고 합니다. 하지만 Intrinsic 함수들이 지원되죠. 이 함수들을 사용하면 이에 해당하는 Assembly 명령어들이 바로 직접삽입되게 됩니다. 이에 대한 내용은 아래 링크를 보시기 바랍니다^^.
한 번 찾은 자료를 정리해 보았는데, 보기보다 많은 차이점이 존재하는 군요. 특히 __int64 라는 것은 기존 x86 Legacy 코드들과의 소스레벨 호환성을 위해서가 아닌가 생각합니다. 기존 소스를 많이 변경해야 한다면 문제점이 많이 생길테니까요. 그래서 32비트에서도 WORD를 32비트로 지정하지 않고 DWORD를 추가함으로써 지원했던것이 이유가 아닐까 합니다. 개인적으로 특히 __fastcall을 통한 많은 성능 향상을 할 수 있을것 같네요.
-b
댓글을 달아 주세요
관리자만 볼 수 있는 댓글입니다.
음.. 한글화 파일 0.5 버젼은 따로 네이버 동방환상마작 까페에 보시면 있을겁니다.
리비젼 2는 되지 있지 않구요.. 1만 된 상태에 그것도 완전하지는 않습니다.