드디어 긴긴 Single Core Processor 관련 부분을 마무리하고 Multicore Processor쪽으로 들어갔습니다. 이번에는 가장 기본이 되는  MP Configuration Table을 분석하는 기능을 추가했습니다. MP Configuration Table은 BIOS에서 만드는 것으로, 코어의 개수와 인터럽트 연결에 관련된 포괄적인 정보를 담고 있습니다. ;) 아래 그림을 보는 게 더 빠를 듯...

MP Configuration Table을 분석하는 이유는 실제 Core의 개수를 찾는 것과 나중에 인터럽트를 모든 Core로 전달하기 위해서입니다. BIOS는 부팅 과정에서 부팅을 담당하는 프로세서인 BSP(Bootstrap Processor)로 PIC 컨트롤러의 인터럽트 라인을 연결하므로, AP(Application Processor)를 깨운다 해도 PIC 컨트롤러의 인터럽트는 전달되지 않습니다. ;) 전달된다 하더라도 PIC 컨트롤러는 Multicore Processor를 지원할 능력이 없으므로 오동작하겠지요. ;)

따라서 Local APIC와 I/O APIC를 이용해서 모든 Core로 전달되도록 설정해야 하는데, 이때 MP Configuration Table에 저장된 정보가 아주 중요한 역할을 합니다. 실제 메인보드 제조사는 인터럽트를 어떻게 연결했는지를 알고 있으므로, BIOS에 그 정보를 저장해 둡니다. 이 정보가 MP Configuration Table에 들어 있는 것입니다. 만약 MP Configuration Table을 사용하지 않는다면... ㅎㄷㄷ... 생각만 해도 이건... ㅠㅠ

여튼~!!! 분석하는 게 끝났으니 이제 깨워서 일 시키는(?) 일만 남았군요. ㅎㅎ 아우 진짜 죽겠습니다. 이것만 끝나면 GUI로 바로 날아갈 텐데... ㅠㅠ  좀이 쑤셔 죽겠군요. ㅎㅎ 다음 작업도 끝나는 대로 인증 샷을 올리겠습니다. 다음 인증 샷에는 쌍둥이(?)가 열심히 일을 하는 화면이 나오겠군요. ;)

그럼 다들 좋은 저녁 되세요 ;)

ps) 아래는 QEMU의 MP Configuration Table의 내용입니다. 실제 PC와는 좀 다른 모습이군요. ;)



이번에도 상당히 오랫동안 작업했습니다. 요즘은 귀차니즘이 도져서 가만히 않아서 작업하는 게 힘듭니다. 그래서 약간 진도도 처지고 의욕이 살살 꺼지고 있습니다. 그래도 갈 길이 멀기에 끙끙거리면서 작업해서 겨우 붙였군요. ;)


일단 말이 필요 없으니, 직접 한번 보시죠. ;) QEMU에서 실행해서 새 그림이 그려 진 텍스트 파일을 수신한 후, 그것을 다시 화면에 표시한 동영상입니다. 화면을 캡쳐한 것을 올려도 되지만, 동영상이 좀 더 액티브(??)하니 동영상으로 올렸습니다.


<동영상 파일을 변환하니 깨져서 그대로 올렸더니 파이어폭스에서는 제대로 안보이는 문제가 있네요. ㅠㅠ>

https://t1.daumcdn.net/cfile/tistory/13153C1B4A31337702 를 클릭하시면 다운로드 받아서 볼 수 있습니다.



파일 시스템이 생기니 이런 재미난 일도 할 수 있군요. ㅎㅎ 너무 신납니다. ;) 그러고 보니 OS의 기본 기능은 대부분이 구현되었군요. 이제 남은 건 멀티 코어를 활성화하는 부분이랑 GUI 정도인 것 같은데... 다음 이번 달과 다음 달은 꽤나 고생하겠다는 생각이 드는군요. ㅠㅠ 어흑 언능 작업해서 재미난 GUI로 가고 싶어요. ㅠㅠ 그럴려면 또 열심히 달려야겠군요. 어흑...

그러기 전에 오늘은 일단 좀 쉬어야겠습니다. 피곤에 너무 찌들어서 한참을 골골거렸다는 ㅋㅋ 그럼 다들 좋은 밤 되세요. ;)


ps) 다음은 MINT64 OS에서 전송한 ASCII Art 파일을 표시한 것을 캡쳐한 화면입니다. 예전에 쓰던 마스코트인 까마귀입니다. 어때요? 비슷하죠? ㅎㅎ


아아~ 간만에 쓰는 포스팅인 것 같군요. ㅠㅠ 원래는 지난 주에 끝났어야 하는 작업인데... 클러스터 크기를 4Kbyte로 잡았더니만 테스트하는데 문제가 생겨서 포스팅이 늦어지고 있습니다. ㅠㅠ

파일 시스템을 워낙 허접하게 만들어 놓아서 1바이트를 읽고 쓰는데 성능이 엄청나게 떨어지네요. 좀 편하게 구현하려고 4Kbyte 단위로 하드 디스크를 읽고 쓰도록 했더니 1바이트를 수정해도 4Kbyte를 읽고 쓰는 기염을 토한다는...OTL... 털썩... 물론 캐시가 들어가면 훨씬 좋아집니다. ㅎㅎ

이거... 캐시를 안 쓰고 성능을 재면 128Kbyte짜리 파일을 한 바이트씩 읽고 쓰는데 무려 10분이라는 시간이 걸리네요. ㅠㅠ 이거 원 부끄러워서... ㅠㅠ 어흑... 그래도 캐시를 쓰면 5분 정도로 줄어드니 그나마 덜 부끄럽다는... ㅠㅠ 사실 10분이나 5분이나 큰 차이는 없지만... 구현을 편하게 하려고 대충했더니만 이런 문제가 생기네요. ㅠㅠ 어흑 눈물이 ㅠㅠ

일단 대충 해놓고 나중에 방법을 좀 강구해야겠습니다(아니면 그냥 쓰던가... 쿨럭..;;;). 그나마 다행인 건 램 디스크도 있으니 급하면 램 디스크를 쓰라고 하면 된다는 거~!!! OTL... 털썩... 일단 정리되는 대로 MileStone을 하나 올리겠습니다. 지금은 성능부터 재야겠군요. ㅎㅎ

그럼 다들 좋은 밤 되시길~ ;)

이번 포스팅은 거의 2주 만에 하는 것 같군요. ;) 이번에는 파일 시스템을 구현하다 보니 양이 많아서 이제야 겨우 끝났습니다. 일단 인증샷부터 보시죠. ;)

<MINT 파일 시스템을 구동한 동영상>

MINT 파일 시스템은 FAT 파일 시스템처럼 클러스터를 링크로 연결하는 형태로 되어 있습니다. 사실 FAT 파일 시스템을 쓸까도 고민했었는데, FAT 파일 시스템을 정리하고 구현하려면 양이 많아질 것 같고, 그렇다고 정리를 안 할 수는 없으니 그냥 간단한 파일 시스템을 만드는 것으로 했습니다. 그래서 나온 것이 MINT 파일 시스템인데 아래와 같은 구조로 만들었습니다.

 

<MINT 파일 시스템의 전체적인 구조>

척 봐도 FAT 파일 시스템과 아주 유사하다는 것을 알 수 있습니다. 디렉터리 엔트리 구조도 아주 단순합니다. 디렉터리 엔트리는 32 byte이며 파일 이름 24 byte와 파일 크기 4 byte, 그리고 파일 시작 클러스터 4 byte가 전부입니다. 클러스터 크기가 4Kbyte이므로 한 클러스터에 최대 128개의 파일을 생성할 수 있습니다.

<디렉터리 엔트리(Directory Entry)의 형식과 루트 디렉터리(Root Directory)의 구조>

이쯤되면 FAT 파일 시스템을 구현하는 게 더 낫지 않냐고 생각할지도 모르겠지만... MINT 파일 시스템은 극단(?)의 제약 사항을 걸어서 구현할 코드의 량을 대폭 줄였습니다. 그 제약 사항이 뭐야 하면...

디렉터리는 클러스터 하나만 사용할 수 있다
디렉터리는 루트 디렉터리만 존재한다

그렇습니다~!!! 서브 디렉터리를 제공하지 않고, 루트 디렉터리의 크기를 고정함으로써 경로(Path)처리나 디렉터리 처리에 관련된 코드를 대폭 줄인 것입니다. 실제로 예전에 FAT 파일 시스템을 구현했을 때와 비교한다면, 1/3 수준입니다. 물론 아쉬운 부분이 있긴 하지만... MINT64 OS처럼 간단한 OS에서 쓰기에는 충분한 것 같습니다. 어렵게 구현하는 것 보다 일단 구현하기 편하고 잘 돌면 되지요. ;)

구현할 양이 작아진 덕분에 C 언어 표준 입출력 함수, 즉 fopen(), fread(), fwrite(), fclose(), fseek(), opendir(), readdir(), rewindir(), closedir() 함수도 구현할 수 있었습니다. 마치 윈도우나 리눅스에서 콘솔 프로그램을 작성하듯이 MINT64 OS에서도 가능하다는 이야기지요. ㅎㅎ 실제로 아래는 위의 동영상에서 파일을 쓰고 읽는데 사용된 코드입니다.



아아~ 이제 파일 시스템에 캐시(Cache)를 넣고 램 디스크를 추가해야겠군요. 원래 이번 주 월요일에 시작해야 했는데 파일 시스템을 만드는 것이 늦어져서 이제야 시작합니다. ㅠㅠ 아흑... 또 주말을 반납해야 한다는... ㅠㅠ 열심히 만들어서 곧 Milestone을 하나 올리겠습니다. ;)

그럼 다들 즐거운 주말 되세요. ;)

아아... FAT 파일 시스템을 그대로 쓸까 하다가 FAT 파일 시스템을 좀 축소해서 아주 간단한 파일 시스템을 만들었습니다. 덕분에(?) 시간은 더 많이 걸리고 기능은 더 빈약(?)해졌군요. ㅠㅠ

예전부터 제가 만든 OS에서만 사용하는 독특한 파일 시스템을 만들고 싶다는 생각을 했었는데, 이제서야 겨우 만들었네요. ^^;;; 사실  FAT 파일 시스템에서 다 추려 내고 뼈대만 남긴 것 뿐이지만... 그래도 나름 뿌듯하다는... ㅠㅠ

일단 오늘은 밤이 좀 늦었으니 자세한 내용은 내일 포스팅 하겠습니다. 아아~ 무지 피곤하네요. ㅎㅎ 요즘 체력도 거의 다 떨어졌는데... 내일은 좀 문제가 있겠군요. ㅠㅠ 아흑 ㅠㅠ

그럼 다들 좋은 밤 되세요 ;)

휴가를 다 반납하고 집에 틀어박혀 작업만 한 결과, 파일 시스템 기본 API를 만들었습니다. 물론 파일 시스템도 허접하게 하나 만들고 말이지요. 그런데 만든 API가 워낙 허접하다 보니 빈 파일 하나를 생성하고 삭제하는 기능 말고는 되는 게 없네요. ㅠㅠ

아흑... 이래서는 안되겠다 싶어서 표준 입출력 함수처럼 open, read, write, close, opendir 등등을 만들고 있습니다. 오늘이 벌써 수요일이니까 이번 주까지 할 수 있을지 모르겠지만, 일단 최선을 다 해야 할 듯 하군요. 에혀... 점점 갈 길은 아직 먼데 체력은 점점 떨어지고 있어서 큰일 났습니다.

무슨 수를 쓰긴 써야 할 때인 것 같군요. ㅎㅎ 일단 좀 더 달려 보고 안되면 특단의 조치(?)를 내려야겠습니다. 홧팅~!!!

ps) 그래도 Milestone인데 아무것도 없으면 허전할 듯 해서, 하드 디스크를 MINT 파일 시스템으로 포맷하고 나온 정보를 표시하는 화면을 올립니다. 어흑... 이런거나 올려야 되다니... 정말 한 게 없군요. ㅠㅠ

clip_image002

<QEMU에 등록된 20MB짜리 하드 디스크의 정보를 읽은 화면>


읏차~ 예상 외에 변수가 생겨서 생각보다 조금 더 걸렸군요. ㅠㅠ 예전에 짰던 코드에 또 버그가 나와서 고칠까 말까 고민하다 보니 시간이 꽤 지났습니다. ㅠㅠ 수정하는 게 당연한데 왜 고민한 건지 잘 모르겠네요. (잠결에 그랬나? ㅡ_ㅡa..)

<LBA 0 어드레스에 2 섹터를 쓴 화면>

일단 간단히 읽고 쓰고를 반복해 본 결과 별 문제가 없는 것 같으니, 파일 시스템으로 넘어가야겠습니다. 파일 시스템은 FAT 파일 시스템을 아주 가볍게 개량해서 만들 생각입니다. 글은 이렇게 썼지만 사실 이미 작년 이맘때쯤에 만들었습니다. ㅡ_ㅡa;;; 아주 허접하지만 FAT 파일 시스템 드라이버를 만드는 것보다 일도 작고(과연??) 나름대로 쓸 만해서 이걸로 가기로 했습니다. 뭐 이름은 MINT64 Simple File System으로 해서 MSFS....가 아니라 MINTFS로 해야겠군요. ㅡ_ㅡa... 어디서 많이 본 듯한 이름이... 쿨럭..;;;


아아~ 또 바쁘게 하나 해야겠습니다. ㅎㅎ 이번 주말에 파일 시스템 스크린샷을 올릴 수 있으면 좋을 텐데.... ^^;;; 일단 열심히~!!! 그럼 다들 좋은 밤 되세요 ;)


하드 디스크 디바이스 드라이버 관련 링크는 아래를 참고하세요

http://www.nondot.org/sabre/os/articles/DiskandDiscDrives/

와아~ 드디어 또 기다리던 주말이군요. ㅠㅠ)-b 이번 주도 컨디션 난조로 거의 버리다시피 해서 주말에 작업을 많이 해야 하지만... 고향에 가야 돼서 이번 주도 좀 어렵겠군요. ㅠㅠ 요즘 날씨가 이상해서 그런지 영 컨디션이 좋지 않습니다. 머리가 마치 굳어 있는 듯한 느낌이랄까요? 귀도 머엉~ 하게 울리고... ㅠㅠ

그냥 다 때려치우고 잠시 쉬고 싶은 마음도 있지만... 영 쉽지 않네요. 지금 쉬면 뒷탈이 생길 것 같아서 어떻게든 작업을 하려고 노력 중입니다.(누가 상 안주나요? ㅎㅎ) 열심히 해서 이번 주도 Milestone 하나를 올려야 할 텐데... 벌써 걱정이 태산이군요. ㅠㅠ

또 끄적 끄적거려 봐야겠습니다. ㅠㅠ 다들 즐거운 주말 되세요 ㅠㅠ)/~

<64MB 영역 중에서 17MB를 커널 영역으로 사용하고 나머지 47MB를 동적 메모리 영역으로 할당한 화면>

아아~ 정말 이번 내용은 길고 지루했습니다. ㅡ_ㅡa... 내용 정리하는데 거의 9일이 걸렸고, 쓴 내용을 검토하는데 거의 5일이 걸렸습니다. ㅠㅠ 동적 메모리 할당과 해제에 대한 내용이다 보니 다른 스텝보다 좀 아니 훨씬 많더군요. 진짜 죽는 줄 알았습니다. ㅠㅠ


그래도 온몸을 배배 꼬아 가며 정리한 보람이 있는지 마무리하긴 했습니다. ;) 그리고 무시무시한 버그도 녀석도 하나 잡았지요. ㅎㅎ 지난번에도 캐시를 잘못 설정해서 GUI의 속도가 무진장 느린 문제가 있었는데, 이번에도 캐시 때문에 메모리에 접근하는 시간이 무지 걸리는 문제가 발생했습니다(이전에 발생한 캐시 문제는 http://kkamagui.tistory.com/608 에서 볼 수 있습니다).  지난번에 당한 게 있어서 금방 해결은 했는데... 왠지 좀 씁쓸하더군요. 약 10 챕터 정도를 거슬러 올라가서 다 수정해야 했기 때문입니다. ㅠㅠ 아흑... 몇십 분을 삽질하려니 죽을 맛이었습니다. 그래도 일찍 찾아서 다행이네요. ^^;;;; 저쪽 뒤에서 찾았다면 아마 기절했을 듯합니다. ㅎㅎ 이만하길 다행이랄까요?


동적 메모리를 처리하는 알고리즘으로는 제가 즐겨 쓰는(?) 버디 블럭 알고리즘(Buddy Block Algorithm)을 썼습니다. 버디 블럭 코드만 4번째 구현하는데, 이번이 그나마 제일 깔끔한 것 같네요. 나름대로 튜닝도 해서 속도도 만족스럽게 나오고... ^^;;; 혼자 쓸게 아니라서 신경 좀 썼습니다. MINT64 OS에서 구현한 방법은 나중에(?) 공개하겠습니다.


버디 블럭 알고리즘이 궁금하신 분은 http://kkamagui.tistory.com/20 를 참고하기 바랍니다(예전에 만든 자료라서 좀 부실하지만 어떤 원리로 동작하는지 확인하는 용도로는 괜찮을 듯 하군요. ^^a... ).


에혀~ 그러고 보니 또 한 주가 사라졌군요. ㅠㅠ 이러면 안 되는데... 언능 작업 들어가서 부족한 시간을 보충해야겠습니다. 그럼 다들 즐거운 주말 되세요. ;)

아핫~ 너무 신납니다. ^^)-b 또 즐거운 주말이군요. ㅎㅎ 이번 주는 MINT64 OS에 동적 메모리 할당 & 해제 기능을 넣고 있는데, 역시나 주중에 주식 때문에 거의 작업을 못해서 주말 내내 짱 박혀 작업할 것 같습니다. >ㅁ<)-b 밖에 나갈 시간도 없지만 괜시리 주말이라 설례는군요(그러고 보니 회사 가는 날보다 더 빡신듯... ^^;;;;)

이번 주 투자 현황을 굳이 표현한다면....

난~~ 계속 오를 것 같았던 주식은 살살 떨어지고 있고~ 유상 증자니 하는 소리가 들릴 뿐이고~ 그냥 엄마가 보고 싶고~ ㅠㅠ 작업은 밀려서 당장 내일이 안보일 뿐이고~!!! 

대략 이런 상황이네요. ㅎㅎ 정말 주식처럼 깜깜한 주말입니다. ㅎㅎ

에혀~ 그래도 열심히 해야지 어떻게 하겠습니다. ㅎㅎ그나마 성격 하나는 낙천적이라 다행인 듯 하군요. ^^;;; 이번 주말에도 Milestone 하나 올릴 수 있도록 열심히 해야겠습니다. ;)

그럼 다들 즐거운 주말 되세요 ;)

근 3주만에 Milestone이군요. ;) 3주동안 감기 몸살에 멤버십 후배들 호출에... 뭐 기타 등등이 섞여서 작업이 좀 더뎠습니다. 덕분에 2주 동안 해야할 분량을 3주나 되서야 겨우 끝냈군요. ㅠㅠ 아흑... 피 같은 한주가 그냥 사라져 버렸네요. ㅠㅠ

3주동안 MINT64 OS에 많은 변화가 있었습니다. 첫 번째는 멀티 태스킹과 멀티 스레딩 기능이 추가되었다는 것이고 두 번째는 실수 연산 기능이 추가되었다는 것입니다. 이 두가지 기능이 추가됨으로써, 태스크 관리쪽이 거의 마무리 되었네요. ㅎㅎ

역시 기념으로 스크린 샷을 찍어 올립니다. 그리고 이번에는 좀 특별하게 동영상도 찍었습니다. ;) 왠지 정지해 있는 화면만으로는 뭐가 어떻게 돌아가는지 확인하기 힘들 것 같아서요... ^^;;;;

아래는 첫 번째는 원주율의 근사값을 계산하는 화면이며, 두 번째는 MINT64 OS를 테스트하는 동영상입니다. 워낙 허접해서 볼 건 없지만 기념삼아 찍어봤습니다.

<원주율을 계산하는 테스트>


<테스트 동영상>

어휴~ 이제는 동적 메모리 관리랑 파일 시스템쪽을 구현해야 하는군요. ㅠㅠ 어흑 어찌나 갈길이 먼지... 머리가 살살 아프네요. ㅠㅠ 일단 자고 내일 생각해야겠습니다. ㅠㅠ

그럼 다들 좋은 밤 되세요 ;)

ps1) 파일 압축쪽도 추가해야하는데... 혹시 소스 파일하나 짜리 Zip 압축/해제 코드를 보신 분은 제보 부탁드립니다. ㅠㅠ 출처를 밝히고 당겨 써야겠어요. ㅠㅠ

ps2) 실제 PC에서 테스트해보니, 더 느리군요. ㅡ_ㅡa... 그래서 태스크의 수를 300개로 줄였습니다. 아무래도 화면에 출력하는 루틴이 시간을 많이 잡아 먹는 듯 하네요. ^^;;;

에궁~ 8시 경에 집에 와서 시간까지 작업을 강행한 결과~!!! 드디어 프로세스와 스레드 관련 부분도 어느 정도 마무리되었습니다. ;) 와아~ 짝짝짝~!!!

거의 끝난 기념으로 무엇을 할까 고민을 많이 했었는데~ 후배가 매트릭스 화면을 만들어 보는 게 어떻겠냐는 이야기를 해서 프로세스 1개와 1021개의 스레드를 이용해서 매트릭스 화면을 만들어 봤습니다. 아래는 인증샷 입니다.

사실 실제로 보면 글자가 줄줄 흘러 내리는 것이 보이는데... ㅡ_ㅡa... 스크린 샷으로는 그런 느낌이 나질 않아서 약간 아쉬움이 남는군요. ㅎㅎ 조만간 실행 파일을 정리해서 한번 올리겠습니다.

아우 벌써 또 이만큼 시간이 지났네요. ;) 일단 오늘은 자고 내일 정리해서 올리겠습니다. ㅎㅎ 다들 좋은 밤 되세요 ;)

거의 3주 만에 올라오는 Milestone이군요. ;) 중간 중간에 올릴 수도 있었는데... 일정에 좀 쫓기다 보니 마음이 급해서 그러질 못했네요. ;)

image

<멀티 레벨 큐 스케줄러가 도입된 화면> 

그 동안 MINT64 OS에 많은 변화가 있었습니다. 그 중에서 첫 번째는 라운드 로빈 스케줄러에서 벗어나 멀티 레벨 큐가 도입된 것입니다. 큐는 0~5까지 총 5개의 레벨로 구분되고, 우선 순위에 따라 적당히 레벨을 설정해 주면 스케줄러가 레벨에 따라 회수를 달리하여 열심히 스케줄링 해줍니다. 위의 스크린샷은 현재 수행 중인 태스크의 우선 순위를 변경한 후, 프로세서 사용률을 출력한 화면입니다. 태스크를 Sleep 없이 계속 실행했더니 사용률이 98%까지 올라갔군요. ㅠㅠ

image

<동기화 수행 전, 숫자의 순서가 일정치 않으며 출력된 카운터의 수가 15개가 안됨>

두 번째는 동기화 처리를 위해 뮤텍스(Mutex)가 추가된 것입니다. 동기화 처리에서 빠지지 않는 것이 두 태스크 간에 변수 하나를 공유하면서 덧셈이나 값을 출력하는 예제인데, OS 책을 몇 권 보신 분은 이제 지겨운 예제일 것입니다. 저도 처음에는 왜 이런 단순한 예제를 가지고 설명하는 것일까 하고 생각했습니다만, 반대 입장이 되어 보니 이제서야 알겠더군요. ㅡ_ㅡa... 그것만큼 설명하기 쉽고 간단한 예제가 없더라구요. ^^a... 그래서 결국 태스크 3개가 하나의 변수를 1씩 증가시키면서 5번씩 메시지를 출력하여 1부터 15까지를 출력하는 예제를 작성했습니다. ㅡ_ㅡa...

동기화를 하지 않으면 당연히 위 처럼 제대로 출력이 안되며... 뮤텍스를 이용하면 아래처럼 예쁘게 출력됩니다. 이제 조금만 더 하면, 어느 정도 실행 테스트 가능한 버전을 공개할 수 있겠군요. ;)

image

 <동기화 수행 후, 숫자의 순서가 1씩 증가하며 총 15개의 메시지가 출력됨>

아유~ 이제 이번 주는 스레드에 대한 내용을 정리해야 하는데... 벌써부터 머리가 아프네요. ㅠㅠ 어쨌거나 열심히 해야겠습니다. 호환, 마마보다 무서운 것이 일정이 밀리는 일이니까요. ;)

그럼 다들 좋은 밤 되세요 ;)

이번에는 정말 아슬 아슬하게 기한을 맞췄군요. ㅠㅠ

시간이 너무 늦었으니 오늘은 그냥 화면만 올리고, 자세한 것은 내일 올리겠습니다. ;)

아래는 실행 화면입니다. ㅎㅎ 5개의 우선 순위를 설정할 수 있도록 수정 되었고, 그 외에 뭐 태스크 종료 기능과 우선 순위 변경 기능, 그리고 프로세서 사용률 측정 기능이 추가되었습니다. ;)

clip_image002

이크~ 이만 자야겠군요. 내일 또 회식이 있어서... ^^;;; 다들 좋은 밤 되세요. ;)

clip_image002[8]

에휴~ 이번 주부터 2주 동안은 MINT64 OS에 스케줄러를 구현할 예정입니다. 이번 주는 다음 주에 구현할 멀티 레벨 큐 스케줄러(Multi Level Queue Scheduler)를 위해 간단한 라운드 로빈 스케줄러를 넣고 있습니다. 좀 있으면 주말인데, 주말에 약속이 좀 있어서 과연 이번 주 안에 끝낼 수 있을지 모르겠군요. ^^;;;;

시간은 점점 흘러만 가고 진도는 잘 나가지 않는 가운데... 뭐 회사에 대한 고민들과 퇴사하는 후배의 모습이 겹쳐서 머리가 좀 뒤죽박죽입니다. ㅠㅠ 이거 원... 이런 불경기에 월급 안 깎이는 것만해도 고마워 해야 할 텐데 말입니다. ㅠㅠ 아무래도 배가 부른 것 같군요. 개구리 올챙이적 모른다고 병특 때 고생한 건 생각도 안 하는 듯... ㅠㅠ

에궁... 정신 똑바로 차려야겠습니다. 홧팅~!!! >ㅁ<)-b

ps) 위의 화면은 라운드 로빈 스케줄러를 구현해서 20개의 태스크를 생성한 화면입니다. 대부분의 OS가 그렇듯이 PIT Interrupt를 통해 태스크를 전환합니다. ^^;;; 원래 각 태스크가 화면 주변을 돌게 되어 있는데, 스크린 샷을 찍다보니 그냥 잡다한 글자만 보이는 군요. 약간 슬프다는(?)...

image 

헥헥... 이번 주와 지난 주에 좀 많이 놀았더니 진도 맞추기가 힘드네요. ^^;;;; 어쨌거나 겨우 맞췄습니다. 아슬아슬 했다랄까요 ^^;;;; 자칫 잘못했으면 오늘 밤도 거의 못 잘 뻔 했습니다. ㅠㅠ 크윽... 이게 뭐 하자는 짓인지... ㅠㅠ

이번 주는 멀티 태스킹에 관련된 기능을 정리했습니다. 멀티 태스킹의 핵심이라하면 당연히 컨텍스트(Context) 관리 기능이므로, 컨텍스트 처리에 대한 함수 위주로 작성했습니다. 결과는 위에서 보시는 것과 같이 대~성공~!!!! 두 개의 태스크가 전환하면서 서로 자기 차례라고 메시지를 우기고(?) 있는 모습입니다. ^^;;;; (사실 예전에 다 만들었던 코드를 붙여 넣은 것 밖에는 없어요 ㅠㅠ)

다음 주는 이것을 확장해서 스케줄러도 추가하고 태스크 생성 및 종료에 대한 API도 추가해서 나름 괜찮은 시분할 멀티 태스킹 기능을 추가할 예정입니다. 점점 회사 일에 압박이 들어오고 있어서 생각대로 잘 될지는 알 수 없지만, 그래도 열심히 하는 것 말고는 방법이 없군요. ^^;;;; 제 유일한 장점이 책상에 오래 앉아 있는 거니 이거라도 살려야지요 ㅎㅎ

아아~ 이제 다음 주를 위해 준비를 좀 해야겠습니다. 다들 그럼 좋은 밤 되세요 ;)

ps) 크윽... 귀신보다 무섭다는 일요일 밤이군요. ㅠㅠ 눈물납니다. 아주 그냥 ㅠㅠ

MINT64 OS에 대해서는 간만에 포스팅하는 것 같습니다. 그 동안 회사 일도 좀 바빴고, 컨디션 난조로 생각보다 진도가 잘 안 나가는 바람에 조금 늦어 졌습니다. 블로그에 포스팅하는 시간까지 아껴가며 집중해야 했기 때문이지요. ㅠㅠ 결국 어쨌거나 목표했던 기간은 맞췄습니다. ㅎㅎ

이번에는 시간에 관련된 디바이스에 대한 기능을 추가했습니다. 흔히들 많이 쓰는 PIT 컨트롤러와 RTC, 그리고 정밀한 시간 측정 시에 사용하는 Time Stamp Counter(TSC)에 관련된 기능을 추가한 것이지요. 그리고 덤으로 쉘에 이러한 정보를 출력할 수 있는 기능도 추가했습니다.

만들어 놓고 보니 뭔가 재미있는 게 없을까 하는 생각이 들더군요. 그래서 마침 PIT도 있고 TSC도 있겠다 싶어서 프로세서의 클럭을 간접적으로 측정하는 코드를 삽입했습니다. TSC가 프로세서의 클럭을 기반으로 동작하는 특성을 이용해서, 약 10초 동안에 TSC가 변화한 양을 구하고 그것을 10으로 나누면 얼추 비슷하게 클럭을 측정할 수 있습니다. 다음은 MINT64 OS에서 측정에 사용한 코드입니다. 아래 코드로 측정했을 때 2667MHz가 나왔는데 실제 PC의 클럭이 2.6GHz짜리이므로 큰 차이가 나지 않는 다는 것을 알 수 있습니다.



이걸로 또 한 고비를 넘었습니다. ;) 이제부터 몇 주 동안은 멀티 태스킹 기능을 작업하면서 정리해야 하는데, 갈길이 막막하네요. ^^;;;; 코드를 짜는 거야 이미 지겹도록 했으니 아무 문제 없는데... 정리가 만만치 않아서... 쿨럭..;;; 이것 참 큰일입니다. 에혀... 그래도 어쨌거나 해봐야지요. >>ㅑ~울~!!!

에궁~ 빡시게 달릴 이번 주를 위해 오늘은 좀 일찍 자야겠습니다. 다들 좋은 밤 되세요 ;)

이번 주 금요일에 급히 쉘 관련 파트를 끝내고, 주말 내내 PIT 컨트롤러쪽 작업을 하면서 문서를 정리하고 있었습니다. 처음에는 진도가 꽤나 잘 나가는 듯 했으나, 언제나 그렇듯이 문제에 봉착했습니다.

PIT 컨트롤러의 카운터 0를 사용하는 경우, IRQ 0 인터럽트가 발생하기 때문에 인터럽트를 통해 간접적으로 타이머가 완료되었음을 알 수 있습니다. 하지만 인터럽트가 "언제나" 가능하지는 않기 때문에, 직접 카운터 0를 읽어서 처리하는 함수를 만들었습니다. 처음 작성한 코드는 대략 아래와 같았습니다.


실행해보니 뭔가 이상했습니다. 함수를 실행하자마자 루프를 바로 빠져나왔기 때문입니다. 이상해서 곰곰히 코드를 보고 있었는데 도무지 감을 잡을 수가 없었습니다. 그러던 중... 갑자기 머리를 팍~!! 하고 뭔가 스쳤습니다. 차를 구할 때 이전 값보다 현재 값이 크다고 생각했기 때문에, (현재 값 - 이전 값)으로 구했는데.... 타이머의 카운터는 증가하는 것이 아니라 1씩 감소했던 겁니다. 즉 이전 값이 현재 값보다 더 크다는 것이지요. ㅠㅠ 코드가 제대로 동작하려면 아래와 같이 순서를 바꿔야 합니다.


어흑... 이것 때문에 몇시간을 날렸는지 모르겠네요. 이것 말고도 손가락으로 초를 쟀다가 시계의 초보다 1.5배는 빨리 카운팅해서... ㅠㅠ 디버깅을 계속한 걸 생각하면... 흑흑... ㅠㅠ 왜 손가락으로 카운팅하는 속도와 초침이 움직이는 속도가 같다고 생각했는지... ㅠㅠ

그래도 어떻게든 해결했으니 다행입니다. 에궁... 이번 주 안에 RTDSC랑 RTC 쪽도 끝내려고 하는데... 시간이 될런지 모르겠군요. 이번 주도 미친듯이 집에 일찍 와야겠습니다.

다들 좋은 밤 되시고, 이번 주도 무사 칼퇴근하시기 바랍니다. ;) 야근불가~!!!

드디어 사고를 치고 말았습니다. ㅠㅠ)-b 어제 기안이 결재 되었다는 이야기를 듣고 출판사에 다녀온 것입니다~!!! 왠지 모를 불안감과 기대감에 가슴이 두근두근하더군요. ㅎㅎ 가서 담당하시는 분도 뵙고 이런 저런 이야기를 나눴는데, 너무 인상 좋으시고 성격도 좋으셔서 깜짝 놀랐습니다. “역시 이 바닥은 둥글 둥글한 사람들이 살아 남는구나” 하는 생각이 들더군요. ;)

한 손에 책을 가득 들고 출판사를 나오면서, 이제 진짜 열심히 해야겠다는 생각이 들었습니다. 뭐랄까요... 분위기가 사뭇 다른걸 느꼈다고나 할까... 지금까지 막연히 열심히 해야겠다고 생각한 게 확 깨면서, 언제까지는 뭐 하고 언제까지는 뭐 하고 이런 계산이 팍~!! 되더군요. 크윽... 이제 잠은 다 잤습니다. ㅠㅠ

올해 안에 마무리하는 걸로 목표를 잡고 열심히 달려 보겠습니다. ;) 화이팅~!!!

ps) 위의 스크린 샷은 현재 작업 중인 콘솔 쉘의 화면입니다. ;) 이것도 이제 곧 마무리 되겠군요.

크악... 이제 슬슬 쉘을 만들까 해서 sprintf() 함수를 구현하고 있었습니다. 처음에는 cdecl을 강제로 줘서 예전에 스택 어드레스로 하던 가변 인자 처리 방법을 써볼까 했는데... 64bit gcc는 cdecl을 줘도 무시하더군요. ㅡ_ㅡa... 그것도 당당히 무시한다는 경고까지 띄우고 말입니다. ㅡ_ㅡa...

그래서 결국 중계 역할을 하는 함수를 하나 둬서, 함수 Call 시에 레지스터로 넘어간 파라메터를 스텍에 집어 넣은 후  sprintf() 함수를 불렀습니다. 스택에 파라메터가 다 들어가 있으니 당연히 예전 방식대로 처리할 수 있었지요. ;) 그런데 의외의 곳에서 낭패를 봤습니다. ㅡ_ㅡa.... 다음 코드를 보시죠. ㅠㅠ


아시는 분은 아시겠지만, “...”으로 함수 파라메터를 정의했다면 다른 함수로 “...” 을 넘겨줄 수 없습니다. 쿨럭..;;; 왜 이걸 생각 못했는지... 그래서 예전에 쓰던 va_arg() 시리즈 물은 혹시 잘 될까 싶어서 써 봤는데... 의외로 링크 에러가 안 나는 겁니다. 그래서 정의된 곳으로 가서 확인했더니 라이브러리 함수가 아닌 builtin 함수를 가리키고 있더군요. ㅡ_ㅡa... 그냥 바로 코드로 전환되어서 링크 에러가 안 났던... ㅠㅠ

진작 이놈들을 썼으면 훨씬 전에 끝났을 텐데... vsprintf() 함수나 구현하고 sprintf()랑 printf()는 vaprintf()를 사용하도록 변경해야겠군요. Calling Convention 때문에 고민 꽤나 했었는데... 왠지 허무합니다. ㅠㅠ 에궁... 이렇게 또 하루를 날려 먹는다는... 그나저나 매번 가변 인자 때문에 고생했었는데, 좋은 걸 알았네요. ㅎㅎ 이제 걱정 안해도 되겠습니다. ;)

아우... 일단 자고 내일 일찍 와서 마무리를 해야겠습니다. 그럼 다들 좋은 밤 되세요. ;)


ps) CharSyam님이 지적하신 내용을 보고 본문을 다시 읽어봤더니, va_arg()를 라이브러 함수인 것 처럼 표현해서, 약간 수정했습니다. 본래의 의도는 va_arg()가 지시하는 함수가 라이브러리 함수가 아니라 builtinXXX 시리즈 함수라는 뜻이었는데, 마치 va_arg() 자체가 함수라는 것 처럼 썼더군요. va_arg() 시리즈는 매크로가 맞습니다. ;) CharSyam님 감사합니다. ;)


좀 있으면 할머니 댁에 가야함에도 불구하고 일정이 좀 밀린지라 미친듯이 작업했습니다(그것도 설날 새벽에 이 짓을..~!!! ㅠㅠ). 그 결과~!!! 일단 목표치까지는 완성했습니다. ;) 아우 이거 원 노가다가 아주 장난이 아니군요. 그리고 생각 난 김에 MileStone 성 글에는 앞에 [MileStone]을 달기로 했습니다.

예전에 한번 달았다가 별로 효용이 없어서 블로그를 옮기면서 안달았는데... 글을 검색하려니 태그로 검색하는 것 보다는 제목으로 검색하는게 더 눈에 들어오더라구요 ㅎㅎ 앞으로 어떻게 될지는 모르겟지만, 일단 다는 걸로 했습니다.

[MileStone]을 달려고 글을 찾던 도중... 64bit로 최초로 전환해서 올렸던 글을 봤습니다. 작년 7월이더군요. 허허... 그후 가능성을 검토하기 위해 한 3개월 투자해서 GUI까지 후딱 만들고 지금 2번째 만들고 있는 건데... 그간 고생이 참 많았던 것 같습니다. ㅠㅠ 수많은 가상 머신들을 테스트하며 무료로 쓸 수 있고 멀티 코어까지 지원하는 놈을 찾기가 쉽지 않더라구요. 개발 환경은 또 왜이렇게 구축하기가 힘든건지... 지금 생각하면 눈물이 앞을 가립니다. ㅠㅠ

어쨋거나 지금은 검증까지 완료된 상태니 다시 그런 고생은 안하겠지요. ;) 옛날 글을 보니 감회가 새로워서 한자 끄적거려 봅니다. ㅎㅎ

이크~ 더 늦기 전에 이만 자야겠군요. 다들 떡국 많이 드시고, 새해 복 많이 받으세요 ;)


프로젝트 홈페이지: http://dev.naver.com/projects/nanumfont/


작년부터 GUI에 사용할 무료 폰트가 없을까 많이 고민했었는데, 어제 웹서핑을 하다가 네이버에서 공개한 무료, 그것도 고정 폭 글꼴을 찾았습니다. @0@)-b 비트맵 방식으로 처리하는데 고정 폭만큼 편한 게 없는지라 테스트를 위해 바로 설치해 봤습니다.


아래의 그림은 제가 주로 쓰는 Bitstream Vera Mono 폰트와 나눔고딕 코딩 폰트를 비교한 것입니다. Bitstream에 비해 샤프한 느낌이 나고 한글이 예쁘게 잘 나온다는 것을 알 수 있습니다. 헷갈리기 쉬운 숫자 0과 영문 O를 쉽게 구분할 수 있도록 한 것도 맘에 드는군요. ;)



<나눔고딕 글꼴>



<Bitstream Vera Sans Mono>


Bitstream을 보다가 나눔 고딕을 보니 약간 어색한 문자가 보이기도 하지만, 공짜로 쓸 수 있고 한글이 예쁘게 잘 나오기 때문에 향후 나눔고딕 폰트를 본 따 GUI를 만들 생각입니다. MINT64 OS가 한층 더 이뻐지겠군요. ;) 프로젝트를 진행하시는 분께 감사의 메일이라도 보내야겠습니다.


아우~ 이제 좀 있으면 고향으로 출발해야 할 시간이군요. 다들 즐거운 설 되시고 떡국 많이 드세요 ;)

아아~  지난 주에 내내 정리하고 작업해서 인터럽트 처리에 기반이 되는 IDT와 TSS쪽 관련 작업을 완료했습니다. 아우~ 이번에는 생각보다 정리할 것이 많아서 아주 식겁했습니다. 분량이 다른 것보다 1.5배나 많아서 죽는 줄 알았거든요. ^^;;;;

이것 참... 역시 어림짐작으로 대충 가늠했더니만, 이런 일이 생기는군요. ㅡ_ㅡa... 이것 말고도 대충 대충 잡아 놓은 부분이 아주 많은데... 살짝 겁이 나기 시작했습니다. 올해 안에 끝낼 수나 있을지 모르겠네요. 이건 뭐... 미친 듯이 정리하지 않는 한 어렵겠다는 생각도 얼핏 들었습니다.

어쨋거나 시작한 일이니 마무리는 해야겠고... 도중에 그만두자니 성격에 안 맞고... 역시 전 고생을 사서하는 타입인 것 같습니다. ;) 죽이 되던 밥이 되던 달려 봐야겠습니다. ;)

이크... 벌써 또 이렇게 시간이 됐군요. 이만 자야겠습니다. 다들 좋은 밤 되세요

ps) 맨 앞의 그림은 Divide by zero 예외를 발생시켜서 임시 예외 핸들러를 부른 화면입니다. 아주 허접하지만 Milestome 용으로 올려 봅니다. ;)

오늘 블로그를 돌다가 Xeraph 님의 블로그에서 재미있는 글을 봤습니다. “인텔 기가비트 NIC의 성능 향상 기법”이라는 내용이었는데, 원문은 http://xeraph.egloos.com/4808876 에서 보실 수 있습니다.

내용을 간단히 요약하자면 기가 비트쯤 되면 초당 무시무시한 패킷이 오고 가는데, 이것을 패킷이 올 때마다 인터럽트를 발생하게 하여 처리하면 인터럽트 처리의 오버 헤드 때문에 시스템의 전체적인 효율이 떨어진다는 것입니다. 어차피 패킷은 주기적으로 들어온다고 가정하면 인터럽트가 아닌 타이머를 사용할 수 있고, 주기적으로 패킷을 한꺼번에 읽도록 하면 효율을 높일 수 있다는 내용입니다.

실제로도 인터럽트가 자주 발생하면 현재 수행 중인 컨텍스트를 저장하고 복원하는 오버 헤드 때문에, 시스템의 성능이 급격히 떨어지게 됩니다. 저도 그런 경험을 한번 했었는데, 이 글을 읽고 나니 번뜩 떠오르더군요. 예전에 2003년쯤 자작한 kkama OS를 구동시키기 위해 펜티엄 2 233Mhz를 가진 노트북을 샀었습니다. Dell사 꺼였는 데, 플로피 디스크를 내장하고 있었기 때문에 상당히 메리트가 있었지요. ㅎㅎ

OS를 만들면서 GUI도 갖다 붙이고, HDD도 갖다 붙이고 하다가 장난 삼아(?) 시리얼 포트 드라이버를 만들 때였습니다. 전송 속도를 115200으로 맞춰 놓고 PC에서 노트북으로 데이터를 전송했더니, 정상적으로 패킷이 수신되지 않는 문제가 발생했습니다. 이상하다 싶어서 전송하는 동안 아무런 작업을 하지 않았더니 제대로 수신되더군요.

몇 번을 반복한 결과 시리얼로 패킷이 전송되는 동안 OS가 비정상적으로 느려지고, 마우스와 키보드, 그리고 HDD의 인터럽트, 그리고 인터럽트 불가 지역을 동시 다발적으로 수행할 때 패킷이 빠진다는 것을 알았습니다. 순진하게 시리얼 포트의 인터럽트가 발생할 때 마다 패킷 하나씩만 읽어 가서 FIFO에 남은 패킷이 계속 인터럽트를 유발했던 것이지요. 그러다 보니 처리가 늦어지고  패킷은 FIFO에서 밀려 사라지고... 등등의 문제가 발생했었습니다.

해결 방안은 간단했습니다. 시리얼 포트의 FIFO 크기를 늘리고, 인터럽트가 발생했을 때 마다 FIFO에 있는 데이터를 모두 읽음으로써 인터럽트의 발생 회수를 줄인 것입니다. 더불어 인터럽트 불가 영역을 줄여서 인터럽트에 좀더 빨리 반응하도록 한 것도 도움이 됐습니다.

안 그래도 지금 OS를 새로 만들고 있는데, 이런 점을 고려해서 잘 만들어야겠다는 생각이 드는군요. 그 동안 잊고 있었는데, 이점을 고려하면서 해야 할 것 같습니다.

에궁... 그럼 이만 또 자야겠네요. ㅎㅎ 다들 좋은 밤 되세요 ;)

에궁... 테스트 버전의 키보드 드라이버를 MINT64 OS에 추가했습니다. ^^;;; 예전에 만든 OS는 필요한 키만 추려서 처리했는데, 이번에는 다 처리하도록 만들었습니다. 뭐 아직 정리가 좀 덜 되긴 했지만, 역시나 기록을 남긴다는 차원에서... ^^;;;

회사에서 맡은 일도 어느 정도 해결 한지라 부담 없이 작업에 몰두했더니, 밤이 꽤 깊었네요. 이만 자야겠습니다 . 자세한 포스팅은 내일 해야겠군요. ㅎㅎ 그럼 좋은 새벽(?) 되세요 ;)

안녕하세요, kkamagui 입니다. ;) 새해가 되어 처음으로 하는 포스팅이군요. 그간 일이 좀 있어서, 일도 좀 하고(휴가인데 말이죠... ㅠㅠ) 코드 정리 작업을 병행하다 보니 이제서야 하나 올립니다. ㅎㅎ 아우 휴가를 정신 없이 보냈네요. 그나마 위로 일찍 올라 왔으니 이 정도는 한 것 같습니다. 계속 밑에 있었다면 아마... GG ㅠㅠ

이제 월요일이 되면 다시 회사로 가야 하는 데... 끔찍하군요. 어디 짱 박혀서 하고 싶은 것만 하고 살 수는 없을까 심히 고려 중입니다. 나이라도 어리면 과감히 퇴사하고 다른 것에 뛰어들어 볼 텐데... 좀 있으면 꺾인 환갑이라 그럴 수도 없네요. ^^;;;; 그냥 회사 다니면서 잠 좀 줄여 이것 저것 하는 정도 밖에는.... 그나마 졸졸하던 칼퇴도 이번 달부터는 힘들듯... ㅠㅠ (아아~ 이거 난 언제 자라는 말이냐... ㅠㅠ)

위에 그림은 새로 정리해서 만든 MINT64 OS의 스크린 샷입니다. 점점 소스 공개가 불투명해지고 있는 상황에서 이런 스크린샷을 올리는 게 과연 옳은 일인지는 모르겠지만... 개발 기록을 남긴다는 차원에서 꾸준히 올리고 있습니다. 어찌됐던 빨리 마무리 되었으면 좋겠는데... 점점 알 수가 없네요. ㅠㅠ

앗... 벌써 시간이 이렇게... 일단 자야겠습니다. ^^;;; 다들 좋은 밤 되시고... 아 아니구나... 좋은 아침 되세요 ;)

http://kkamagui.tistory.com/614에 제 PC에서 테스트한 A20 게이트의 이상 증세에 대해 글을 남겼습니다. 생각 외로 많은 분들이 관심을 가져 주셨는데, 그 중에서 A20 게이트에 따른 주소 공간의 변화에 대한 내용을 한번 정리할 필요가 있어서 글을 하나 끄적 거립니다.

A20 게이트는 아시는 분은 아시겠지만 어드레스 라인 20bit에 관련되어 있습니다. 즉 A20 게이트가 비활성화 될 경우 어드레스 라인 20bit가 강제로 0으로 설정되어 홀수 Mbyte에 접근되지 않는 것이지요. ^^;;;; 물론 코드에서 홀수 Mbyte에 접근할 수 있지만 이것은 다시 짝수 Mbyte에 맵핑됩니다. 아래 그림을 보시면 한눈에 알 수 있습니다. 3Mbyte + 64Kbyte 영역에 접근하는 예를 나타냈습니다.



따라서 이 때문에 코드에서 사용하는 선형 주소는 짝수 Mbyte에 중복 맵핑되는 결과를 가져옵니다. 이로 인해 전체적인 주소 공간은 아래 그림과 같이 변환됩니다.

따라서 1Mbyte 이하의 위치에서 코드가 실행되는 상태에서 1Mbyte ~ 6Mbyte 까지 영역을 모두 0으로 초기화하는 프로그램을 실행한다면, 1Mbyte ~ 2Mbyte 영역을 초기화하는 순간 자신이 실행 중이던 코드 영역(1Mbyte 이하에 있는)을 모두 0으로 초기화하게 됩니다. 실행되는 코드는 1Mbyte 이하의 어드레스에 존재하므로 프로세서는 온통 0x00으로 도배된 코드를 실행하게되고, 이는 잘못된 인스트럭션이므로 예외(Exception)이 발생하게 됩니다. 즉 프로그램이 멈추거나 리부팅하게 됩니다.

이전에 글을 대충썼더니만, 증상에 대해서 오해하시는 분들이 있어서 다시 한번 정리합니다. ^^
휴일인데도 이런걸 하고 있는 걸 보면... 역시... ㅠㅠ)-b 골방 폐인인듯... ㅎㅎ

그럼 다들 즐거운 연말 보내세요 ;)

회사에서 시간이 좀 남아서 정리를 하던 중에, 재미있는 글을 발견했습니다. 글 주제는 Core의 수가 점점 증가하는 것이 대세이고, 이것을 효율적으로 지원하는 것이 처리 속도를 향상시키는데 도움이 될 것이라는 내용이었습니다. 그 문서에 Intel 사이트의 웹페이지 링크가 첨부되어 있었는데... CPUID를 사용해서 물리적인 Core Processor와 Hyper Threading Logical Processor의 수를 검사하는 방법이 나와 있었습니다.

나름대로 깔끔한 문서라서 회사에서 킵(?) 한 다음 집에 와서 키워드로 검색하니, 이번에는 동영상 강의가 나오더군요. @0@)-b PDF로 작성된 문서보다 훨씬 깔끔하게 정리되어 있어서 공유 차원에서 올립니다. 동영상 강의는 http://software.intel.com/en-us/articles/hyper-threading-technology-and-multi-core-processor-detection 에서 볼 수 있습니다.

제가 만드는 MINT64 OS에서는 Performance를 크게 고려하지 않기 때문에, Core Processor인지 Hyper-Threading Logical Processor 인지 굳이 구분하지 않습니다. 만약 같은 Package에 있는 같은 Core인가, 아니면 같은 Core에 있는 Hyper-Threading Logical Processor인가 판단하여 적절하게 스케줄링하면 보다 높은 Performance를 낼 수 있을 것 같지만... 자세한 건 실제로 벤치마킹한 문서를 봐야 알 것 같습니다. 나중에 시간 나면 Core나 Hyper-Threading에 따라서 어떻게 스케줄링해야 하는지도  한번 봐야겠습니다. ㅎㅎ

차 시간이 다가와서 이만 가야겠군요. ;) 다들 메리 크리스마스~!!!

image

어제 후배에게 테스트를 부탁한 뒤로 생각한 것인데, 각 PC 별로 64bit 및 멀티 코어 검사에 문제가 없는지 확인할 필요가 있을 것 같습니다. 지금 상황으로 보니 프로세서가 64bit 모드를 지원하더라도 BIOS나 기타 문제 때문에 64bit로 전환되지 않는 문제가 있는 것 같더라구요. ㅎㅎ

좀더 자세한 내용은 실제로 테스트를 해봐야 알겠지만... AMD 프로세서 쪽도 체크해 볼 필요가 있을 것 같습니다. 지금까지는 Intel이나 AMD나 64bit 쪽 전환하는 과정이 같다고 가정하고 작업을 했었는데... 순간 아닐 수도 있다는 생각이 들었습니다. 마침 이번 주가 즐거운 크리스마스고 고향집(홈 스윗 홈~!!!)으로 내려갈 예정이니 고향집에 있는 PC(AMD PC)를 마구 굴려서 정보를 뽑아 낼 예정입니다. 그리고 테스트 결과를 여기 블로그나 스프링노트쪽에 올려야겠습니다.

이거 원~!!! 할 일이 태산이군요. ;) 그나마 다행인 것은 틈틈이 책을 좀 봐서 리뷰는 대충 끝냈다는 거~!!! 이제 문서만 만들면 되는데... 왜 이렇게 문서를 만들기가 귀찮은지... 그냥 스프링노트에 끄적거린걸 바로 날려 버리고 싶은 충동이 마구 마구 밀려옵니다. ㅠㅠ)-b 그래도 처음하는 리뷰이니만큼 신경을 좀 쓰긴 써야 할 것 같군요. ㅎㅎ 아흙~!! ㅠㅠ

에궁... 이제 그만 슬슬 자야겠습니다. 사실 잔다기 보다는 몬스터 헌터 2G에 재미를 붙여서 그거 좀 하다가 잘려고... (‘’ )a... 이래도 되는 건지 잘 모르겠군요. ㅠㅠ)-b

그럼 다들 좋은 밤 되시고, 크리스마스 준비 잘하시길~ ;)

ps) 윗부분에 스크린샷은 A20 게이트를 활성화하고 찍은 겁니다. ㅎㅎ 뭐 키보드 컨트롤러를 사용해서 On 하는 건 이제 구식이라 BIOS와 시스템 컨트롤 포트를 사용해서 깔끔하게 처리했습니다. ;) 세상 참 좋아졌군요. ㅎㅎ

지금 A20 Gate에 대한 내용을 정리하고 있습니다. 뭐 예제로 보는 것이 가장 확실해서 간단한 예제를 하나 만들어 제 PC에 동작시켜 봤는데... 일반적인 상황이라면 분명히 죽어야 하는 예제인데 이상하게 버젓이 살아서 동작하는 겁니다. @0@... 혹시나 해서 이것 저것 테스트 해봤습니다만, A20 Gate 쪽이 완전히 동작하지 않는 것 같았습니다. 이제 XT 시절에 쓰던 프로그램을 다시 돌릴 일이 없으니, 무의미하긴 하지만.... 없으니 뭔가 좀 허전하더군요. 에러를 발생시키기 위해서 A20 Gate를 비활성화 했음에도 불구하고 잘 동작하는 것 보면 작동 안 한다고 보는 것이 맞겠지요. ㅎㅎ

혹시나 해서 후배 PC에 돌려봤는데, 일단 후배 PC는 자동으로 A20 Gate가 켜지는 건 아닌 것 같았습니다. A20 Gate를 끄고 OS를 부팅했을 때는 계속 리부팅 되더라구요. ^^;;; 그런데 이상한 점은 64bit 모드로 전환되지 않는 다는 것이었습니다. 정상적인 상황이라면 64bit로 전환되어 커널이 실행되어야 함에도 불구하고 64bit로 전환하는 곳에서 멈춰 있었습니다. ㅡ_ㅡa...

원인은 좀 더 살펴봐야 알겠지만... 살짝 골치가 아프네요. ㅎㅎ 이거 원... 프로세서가 64bit를 지원하는 것 만으로는 안되는 것이 있나 봅니다. ㅠㅠ 어흑... 머리야...


ps) A20 게이트와 주소 공간에 대해서는 따로 정리를 한번 했습니다. ;)

http://kkamagui.tistory.com/619

+ Recent posts