블로그는 귀차니즘

  VS.net 2008에서 몇일 전 컴파일러 옵션에 대해서 이렇게 저렇게 조절을 하면서 저도 처음으로 OpenMP라는 옵션이 있다는 것을 알게되었습니다. 그냥 이름만 딱 봤을땐 Multi Process에 관련된 기능이라는 느낌이 오더군요. 예전에 C#에서 멀티 프로세싱에 관련된 어떠한 라이브러리에 대한 소개를 보았기 때문에 혹시 그런 종류가 아닐까 했습니다.
  찾아보니 위에 언급한 라이브러리 부류더군요. 다만 다른 점은 Directive로 정의된다는 것일까요. 뭐 일단 OpenMP의 특징은 "공유 메모리를 사용하는 환경의 병렬화 프로그래밍의 표준"입니다. 고로 다른 플랫폼에서도 사용할 수 있습니다. 제가 찾아보니 리눅스에서도 가능하고, 썬 스튜디오 컴파일러에서도 가능하군요. 썬 스튜디오 컴파일러에서 된다면 x86서버 쪽일지라도 솔라리스에서 될지도 모르겠군요. 일단 Open그대로 여러가지 환경에서 사용될 수 있다는 것에 대해서는 무척 환영합니다. 사실 이런 기능이 하나, 둘 추가될 때마다 C++이란 언어가 괴물이 되어간다는 생각을 떨쳐버릴수가 없군요. 일단  간단한 예는 아래와 같더군요.

Atomic.cpp (Language : cpp)

1. // omp_atomic.cpp
2. // compile with: /openmp
3. #include <stdio.h>
4. #include <omp.h>
5.  
6. #define MAX 10
7.  
8. int main() {
9.    int count = 0;
10.    #pragma omp parallel num_threads(MAX)
11.    {
12.       #pragma omp atomic
13.       count++;
14.    }
15.    printf_s("Number of threads: %d\n", count);
16. }

  Directive로 이루어지다 보니 num_threads에 해당하는 Thread의 개수를 지정하여 아래의 블럭을 실행하는 쓰레드를 MAX개수 만큼 생성하여 해당 atomic에 대한 Multiple Write Protect를 수행하게 됩니다. 결국 수행하는 것만으로도 CPU에 대한 쓰레드 점유를 늘릴 수 있다는 거죠. 굳이 쓰레드를 여러가지 써가면서 작동하는 코드를 직접 써주지 않아도 된다는 말이됩니다.
  물론 Thread 라는게 실질적으로 하나의 CPU에서 돌아갈 때는 Register에 자료를 저장한 다음, 다음에 수행해야 할 명령에 의하여 자료가 조작되기 때문에 돌아가는 속도가 빠를 수도 있기 때문에, 메모리에 액세스하여야 한다는 점을 유의하여 코드를 작성해야 합니다.
  그리고 무조건 적인 Directive로만으로 이루어진 것은 아니더군요. 언어에 맞도록 lib를 통한 해당 헤더를 인클루드하게 되면 OpenMP에 해당하는 함수를 사용할 수도 있습니다.

num_thread.cpp (Language : cpp)

1. // omp_get_num_threads.cpp
2. // compile with: /openmp
3. #include <stdio.h>
4. #include <omp.h>
5.  
6. int main()
7. {
8.     omp_set_num_threads(4);
9.     printf_s("%d\n", omp_get_num_threads( ));
10.     #pragma omp parallel
11.         #pragma omp master
12.         {
13.             printf_s("%d\n", omp_get_num_threads( ));
14.         }
15.  
16.     printf_s("%d\n", omp_get_num_threads( ));
17.  
18.     #pragma omp parallel num_threads(3)
19.         #pragma omp master
20.         {
21.             printf_s("%d\n", omp_get_num_threads( ));
22.         }
23.  
24.     printf_s("%d\n", omp_get_num_threads( ));
25. }

  결과는 MSDN에 존재하는 대로 1, 4, 1, 3, 1 그대로 나오더군요. 기본적으로 해당하는 Directive 명령어들과 연계가 되어 작동하는것 같군요. 뭐 결과를 보면 그렇게 말할 수 밖에 없겠습니다. #pragma pack(1)과 같이 기존 코드 생성에 해당하는 것을 변형시키는 지시자에 비하여, 실질적으로 생성되는 코드가 다르겠지만 사용자가 사용하는 프로그래머 측면에서는 결과를 모르게 사용할 수 있게 했다는 것에 대하여 큰 가산점을 주고 싶군요.
  왠지 여러가지를 살펴보면서 얻는게 꽤 많은 것 같은데, 다들 유용하게 사용해보셨으면 좋겠군요^^;

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

  말 그대로 Visual Studio.Net 에서는 Original Raw Binary를 생성할 수는 없을까요?? 다른 것은 안 바라고 Raw Binary생성을 원하는데 생각대로 되지 않는군요. VS의 프로젝트 옵션을 자세하게 살펴볼겸 현재 고집스럽게 시도해보고는 있는데, 아직 길을 발견하진 못했습니다. 그래서 안되면 기존에 사용하고 있던 Kubuntu 8.04 AMD64를 이용해 볼 생각입니다. 결국 gcc, g++쪽이 되려나요??
  기존에 했던 작업은 프로젝트의 Pre-BuildEvent 에서 nasm으로 부트로더 이미지를 생성한 후, 커널 및 필요 Asm모듈을 Visual Studio의 x64컴파일을 이용한 코드로 인한 Binrary를 받아 Post-BuildEvent에서 두 개의 이미지를 합치려고 했습니다. 물론 합칠 때 부트로더가 2차 부트로더가 있느냐 보고 있으면 얼마나 불러와야 할지, 커널 이미지도 얼마만큼 불러와야 되는지 까지 다 구현해놨는데, 정작 Vs에서 발목이 걸리는군요^^;



  위 그림은 생성되어 합쳐진 이미지입니다. 온갖 옵션을 만져봤는데, 아직 이렇다 할 방법을 찾지는 못했습니다. 아주 예전에 VS 6.0과는 달리 .Net2003부터는 메모리 공간을 낭비한다고 한 것을 본 기억이 있는데, 그 것이 이 결과일런지는 모르겠네요. 사실 VS에서는 UNICODE에 대해서 UCS2를 사용하고 GCC에서는 UCS4인 것으로 알고 있기 때문에, short를 써가면서 구현하는게 왠지 좀 그럴 것 같아 이 길을 택했는데 어찌 될지 모르겠습니다.
  그나저나 /SUBSYSTEM 옵션을 보니 흥미로운 옵션이 존재하는군요. NATIVE를 비롯해서 CONSOLE, WINDOWS야 그렇다치고 EFI_APPLICATION, EFI_ROM, ... 같은 차세대 EFI와 관련된 옵션인 것 같아 왠지 흥미가 동합니다. 비스타에서 지원한다는 EFI 때문에 2008에 추가되었던 것일까요^^?
  일단 정 안되면 nasm도 Kubuntu에서 sudo apt-get install nasm해서 테스트 해본 바 동일한 결과가 나오니 그 쪽에서 작업할 까 생각중입니다. 혹시라도 알고 계시는 분은 연락 주세요~.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

  보호모드 진입을 위해서 IA32&64 문서를 보고 있군요. 그래도 대충 얻은게 여러가지가 있군요. 사실 보호모드 진입을 위해서 너무 많은 것이 필요하리라 생각하였는데, 예상외로 적은게 필요하더군요. 더불어 x64인 롱모드로 진입을 하려면 32비트 보호모드를 진입한 뒤, 페이징을 비활성화한 뒤, PAE를 활성화 하는 등의 작업을 마련하고 다시 페이징을 활성화 하면 되는 것을 알겠더군요. 물론 그게 실제 코드로 진행 되었을 때 쉬우리라는 보장은 없습니다^^;
  일단 GDT, LDT, IDT에 대해서는 그래도 어느정도 파악이 된 것 같습니다. 몇 가지 의심되는 것이 확인 된다면 바로 코드를 작성할 수 있겠군요. 그나저나 별도의 컴파일이 아닌 한 번의 컴파일로 코드 및 부트로더의 코드 생성을 원하는 데, nasm에서 masm으로 잠시 코드를 변환하여 링크를 걸어봤는데, 뭔지 모르게 약간 안 맞아들어가는 부분이 있군요. 그래도 어떻게 방법을 찾으면 있을것 같기는 합니다. 개인적으론 VS.net 이 IDE중에선 가장 편하기 때문에 VS.net으로 해보려고 하는데, 쩝쩝 아직 잘 되지 않습니다.
  자료를 더 살펴본 뒤, 진행된 결과를 올려보도록 하겠습니다^^.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

  음 일단 진행 됬던건.. BIOS가 처음 POST 과정을 끝내고 BIOS에서 지정된 순서로 부팅 디스크를 검색하여 Magic Sign에 해당하는 첫 번째 디스크의 첫 번째 섹터를 7C00h 번지로 올려준다는 것을 전제로 간단한 Hellow World 출력까지 진행했었기에, 어제 자기전까지 섹터 읽는 것을 구현을 해봤죠. 뭐 그다지 복잡한 것은 아니지만 괜히 삽질하고 있었더군요.

Sector.asm (Language : asm)

1. [org 7C00h]
2.  
3. EntryPoint:
4.     mov ax, 0000h
5.     mov es, ax
6.     mov ax, 0201h
7.     mov cx, 0002h
8.     mov dx, 0000h
9.     mov bx, 7E00h
10.     int 13h
11.  
12.     jmp PrintPoint
13.  
14. times 510-($-$$)    db 0
15.     dw 0AA55h
16.  
17. %macro PRINT 1
18.     pop dx
19.     mov di, %1
20.  
21.     mov ah, 0Eh
22.     xor bx, bx
23.     mov cx, 14
24.  
25. printloop:
26.     mov al, byte[di]
27.     int 10h
28.     inc di
29.     loop printloop
30. %endmacro
31.  
32. PrintPoint:
33.     mov ax, 1301h
34.     mov bx, 0007h
35.     mov cx, 21
36.     mov dh, 0
37.     mov dl, 0
38.     mov bp, MSGLOAD
39.     int 10h
40.  
41.     ;PRINT MSGLOAD
42.  
43. Loading:
44.     jmp Loading
45.  
46. MSGLOAD equ $
47.     db "Message from Sector 2"

  일단 예전과는 다르게 PrintPoint로 EntryPoint를 변경한 뒤, 512바이트 뒤로 명령어 데이터를 옮겼습니다. 왜 이렇게 했냐하면 플로피디스크에서야 잘 모르겠지만 나중에 하드디스크 MBR에 이미지를 Write하여 부팅을 하려고 할 때, 파티션 데이터에 대한 처리를 쉽게 허용하기 위해서 였죠.
  기본적으로 한 섹터는 512바이트이기 때문에, 첫 번째 512바이트는 7C00h번지로 올라가게 되고, 512 바이트 뒤의 데이터는 플로피 같은 디스크 매체에 그대로 남아있게 됩니다. 별도의 로딩과정이 존재하지 않게 되죠. 하지만 512바이트로는 뭐 콩을 구워먹을래도 할 수 있는 일이 없기 때문에 디스크 매체에서 데이터를 읽어들여야 합니다.
  그래서 INT13H의 02H인터럽트를 통하여 2번째 섹터를 읽어 7C00h + 512바이트 주소인 7E00h번지로 로딩을 하게 설정합니다. 기본적인 인자값은 위키피디아에 존재하므로 그 부분을 감안하여 본 뒤 작성하시면 됩니다. 맨 처음 [ORG 7C00h]라는 Directive로 해당 명령어의 시작 지점이 7C00h라는 것을 알려주었기 때문에 생성되는 Label 및 변수에 대해서 주소값은 7C00h를 상대값으로 가지게 됩니다.
  결국 컨트롤이 쉽게 된달까요. 뭐 어찌되었던 512바이트 이후에 예전에 작성했던 코드를 밀어넣고 INT13H를 호출한 후 해당 메모리 주소로 점프를 합니다. 그럼 섹터가 로딩되기 전엔 쓰레기 값이 들어있었을 메모리에 제대로 된 명령어들이 들어있게 되고, 출력 명령어를 잘 수행하게 되죠. 다만 여기서 중요한 것은 02H에 해당하는 Sector Address는 1이 MBR이고 2가 두 번째 섹터더군요. 너무나 인덱스에서 0에 익숙해져 있는 관계로 1을 적었다가 왜 안되지 했었습니다.

Trash.asm (Language : asm)

1. [org 7C00h]
2.  
3. EntryPoint:
4.     mov ax, 0000h
5.     mov ds, ax
6.     mov si, DAPStruture
7.     mov ah, 42h
8.     mov dl, 00h
9.     int 13h
10.  
11.     jmp PrintPoint
12.  
13. DAPStruture:
14.     db 10h      ;sizeof(DAP)
15.     db 00h      ;zero
16.     db 01h      ;read sector count
17.     db 00h      ;zero
18.     dw 0000h        ;segment
19.     dw 7E00h        ;offset
20.     dq 0000000000000001h    ;number of sector
21.  
22. times 510-($-$$)    db 0
23.     dw 0AA55h
24.  
25. %macro PRINT 1
26.     pop dx
27.     mov di, %1
28.  
29.     mov ah, 0Eh
30.     xor bx, bx
31.     mov cx, 14
32.  
33. printloop:
34.     mov al, byte[di]
35.     int 10h
36.     inc di
37.     loop printloop
38. %endmacro
39.  
40. PrintPoint:
41.     mov ax, 1301h
42.     mov bx, 0007h
43.     mov cx, 21
44.     mov dh, 0
45.     mov dl, 0
46.     mov bp, MSGLOAD
47.     int 10h
48.  
49.     ;PRINT MSGLOAD
50.  
51. Loading:
52.     jmp Loading
53.  
54. MSGLOAD equ $
55.     db "Message from Sector 2"

  별개로 이 것은 위키피디아를 읽다가 42H에 해당하는 기능이 읽어보니 훨씬 좋은 기능을 지원하길래 혹시나 하고 작성해봤던 코드입니다. 액세스할 수 있는 주소가 엄청 크기 때문에 원하는 곳을 모두 액세스 할 수 있었는데, 어제 테스트해본 결과론 죽어라 해도 안되더군요. 결국 오늘 까마구 횽님과 대화하다가 다른 문서에서도 플로피에 대한 언급이 없었다고, 이 것은 아무래도 하드디스크에서만 지원하는 것 같다는 결론을 얻게 되었습니다.
  그럼 오늘은 시간이 될 지는 모르겠습니다만 GDT, IDT, LDT에 대해서 자료를 보고 한 번 설정을 해봐야 겠군요^^. 뭐 어떻게 될지는 잘 모르겠지만 잘 되리라 믿습니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

  그냥 무턱대고 삽질을 감수한 뒤에 맹글어본 간단한 부트로더 입니다. 친구이름을 찍어서 스샷을 보내주느라 문자열이 DongWoo Kerenl이 되어버렸군요. OS제작을 위해서 예전에 잡다하게 모아두었던 자료에서 필요한 자료를 빼내 썼습니다. 처음에 MASM으로 만들려고 했는데, link가 없어서 그런건지 약간 이상하여 그냥 맘편하게 nasm으로 만들었습니다.

bootloader.asm (Language : asm)

1. [org 7C00h]
2.  
3. %macro PRINT 1
4.     pop dx
5.     mov di, %1
6.  
7.     mov ah, 0Eh
8.     xor bx, bx
9.     mov cx, 14
10.  
11. printloop:
12.     mov al, byte[di]
13.     int 10h
14.     inc di
15.     loop printloop
16. %endmacro
17.  
18. EntryPoint:
19.     mov ax, 1301h
20.     mov bx, 0007h
21.     mov cx, 14
22.     mov dh, 0
23.     mov dl, 0
24.     mov bp, MSGLOAD
25.     int 10h
26.  
27.     ;PRINT MSGLOAD
28.  
29. Loading:
30.     jmp Loading
31.  
32. MSGLOAD equ $
33.     db "Loading Kernel"
34.  
35. times 510-($-$$)    db 0
36.     dw 0AA55h

  그렇게 복잡한 것은 아니라는 사실을 알 수 있습니다. 다만 그냥 문자열 출력만 되게 만들어 놔서 Loading 라벨에서 계속 Hang up상태의 무한 루프를 돌고 있다는 것을 알 수 있지요. 여기서 문자열 혹은 .문자를 출력하며 하드디스크 인터럽트로 읽어가며 메인 커널 데이터를 읽어오면 될 것 같습니다. 오늘 빨리 퇴근한 김에 해보려고 하는데 잘 될지 모르겠군요^^.
  다 알고 시작하는 늦은 것에 너무 지치기도 하여 그냥 무작정 달려들긴 했지만 앞이 조금 불투명 하긴 하군요. 그래도 나름 잘 되리라 생각합니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.