기본으로 로딩되는 위치에서 벗어나서 다른 위치로 옮긴 다음에 OS를 Loading하는 경우도 발생합니다. 그럴때는 C로 하려면 좀 지저분해지겠죠. 그리고 processor의 mode를 변경하는 등의 작업을 할 때 C로는 좀 힘듭니다. (이런 것을 부트로더에서 하는 경우는 없을 거라고 봅니다만...) 어떤 경우에는 cache를 비우기 위해 반드시 long jump를 해야한다는 등의 제약 사항이 processor 제조사의 매뉴얼에 등장하기도 하니까요. 그 외의 여러 이유로 부트 로더의 초기 진입 부분은 assembly로 짜는 경향이 있습니다.
부트로더는 크기가 작아야 합니다.
부트로더가 빨리 메모리에 적재가 되어야 시스템이 빨리 동작을 할 수 있는데 이 때 부트로더 크기가 크면 그 만큼 로딩시간이 늘어납니다.
그래서 어셈블리어로 부트로드를 작성하여 부트로더의 크기가 줄어들면 부팅시간이나 저장공간에 대한 장점이 생기는 것입니다.
C가 작동하기 위해 가정하고 있는 기본가정이 지켜질 수 없는 경우가 많기 때문에 assembly로 많이 작성합니다.
예를 들어, C로 일반 코드를 작성하게 되면 Compiler가 보통 가정하고 있는 것이
*) read/write가 가능한 stack이 존재하고 stack pointer가 이미 설정되어 있다.
*) rw data가 dram에 load되어 있고 zi data가 0으로 초기화가 되어 있다.
같은 것들이 있습니다. 하지만 부트로더 실행이 시작되었을 때는 stack pointer도 설정되어 있지 않고 dram controller도 아직 초기화되지 않은 상태이므로 dram에 read/write를 해서는 안됩니다. 0으로 초기화 되어 있어야 할 zi data에 쓰레기가 들어있을 것이고 rw data에는 접근을 하면 아직 memory에 rw data를 load도 하지 않은 상태일테니 쓰레기가 들어 있을 것입니다.
그래서 부트로더를 c로 작성한다면
*) dram controller를 초기화하고 stack pointer를 초기화할 때까지 stack사용 금지(function call금지, 과도한 local variable사용 금지)
*) rw data, zi data를 초기화 하기 전에 접근금지
를 해야 됩니다. compiler에 따라서는 #pragma를 덕지덕지 사용하면 회피가 가능한 경우도 있습니다만 종종 불가능한 경우도 있습니다.
예를 들어 부트로더가 특정 address부터 시작하고 부트로더 조금 뒤에 interrupt vector table이 있어야 되는데 부트로더를 c로 작성해서 stack사용을 하지 않기 위해서는 call을 못하는 상황이 발생하면 기술적으로 c로 작성하기가 불가능한 경우도 생기게 됩니다. assembly의 경우에는 이런 경우에 그냥 stack사용 안하고 멀리 다른 곳으로 jump해 버리면 해결이 되겠죠. :)
저는 주로 #pragma 묘기로 부트로더 작성이 가능한 경우에는 #pragma로 작성하고 불가능한 경우에는 c로 부트로더를 먼저 작성한 후에 disassemble을 해서 내용을 보고 assembly level에서 상황에 맞게 수정을 합니다.(예를 들어 stack에 접근하는 부분을 삭제)
c로 부트로더를 만들게 되면 또 하나 위험할 수가 있는 것이 optimize option을 주면 stack을 사용안 안하고 optimize option을 안주면 stack을 사용하는 경우도 있을 수가 있고, compiler가 버전업이 되면서 이전에 stack을 사용하지 않는 code를 생성하던 c 소스코드가 stack을 사용하는 code를 생성할 수도 있기 때문에 특정 compiler version의 특정 compile option을 지칭해서 이렇게 반드시 컴파일하라고 지시해야 됩니다.
cache라던가 mmu라던가 기타등등의 문제도 있지만 일단 저것들이 부트로더를 assembly로 많이 만드는 가장 큰 이유인 것으로 생각됩니다.
경우에 따라서는 코드의 위치를 변경해야 할 경우도 있습니다.
기본으로 로딩되는 위치에서 벗어나서 다른 위치로 옮긴 다음에 OS를 Loading하는 경우도 발생합니다. 그럴때는 C로 하려면 좀 지저분해지겠죠. 그리고 processor의 mode를 변경하는 등의 작업을 할 때 C로는 좀 힘듭니다. (이런 것을 부트로더에서 하는 경우는 없을 거라고 봅니다만...) 어떤 경우에는 cache를 비우기 위해 반드시 long jump를 해야한다는 등의 제약 사항이 processor 제조사의 매뉴얼에 등장하기도 하니까요. 그 외의 여러 이유로 부트 로더의 초기 진입 부분은 assembly로 짜는 경향이 있습니다.
u-boot의 경우
u-boot의 경우 CPU초기화, 메모리설정, 하드웨어 설정등 C에서 못하거나 C startup부분을 대부분 마치고 바로 C가 구동됩니다.
요즘은 boot loader의 기능이 많아지는 경향이 있어서 더더욱 C로 구현하려고 하겠죠.
부트로더는 크기가 작아야 합니다.
부트로더는 크기가 작아야 합니다.
부트로더가 빨리 메모리에 적재가 되어야 시스템이 빨리 동작을 할 수 있는데 이 때 부트로더 크기가 크면 그 만큼 로딩시간이 늘어납니다.
그래서 어셈블리어로 부트로드를 작성하여 부트로더의 크기가 줄어들면 부팅시간이나 저장공간에 대한 장점이 생기는 것입니다.
파일 포맷
실행파일 포맷도 하나의 이유가 될 수 있을것 같습니다.
여기서 궁금한점이 생기는데 C를 컴파일할때 elf 와 같은 포맷 말고 순수 기계어로 컴파일 하기 위한 옵션이 존재하나요?
당연히 라이브러리는 사용하지 않는다는 조건에서요.
Dig it.
Dig it.
C가 작동하기 위해
C가 작동하기 위해 가정하고 있는 기본가정이 지켜질 수 없는 경우가 많기 때문에 assembly로 많이 작성합니다.
예를 들어, C로 일반 코드를 작성하게 되면 Compiler가 보통 가정하고 있는 것이
*) read/write가 가능한 stack이 존재하고 stack pointer가 이미 설정되어 있다.
*) rw data가 dram에 load되어 있고 zi data가 0으로 초기화가 되어 있다.
같은 것들이 있습니다. 하지만 부트로더 실행이 시작되었을 때는 stack pointer도 설정되어 있지 않고 dram controller도 아직 초기화되지 않은 상태이므로 dram에 read/write를 해서는 안됩니다. 0으로 초기화 되어 있어야 할 zi data에 쓰레기가 들어있을 것이고 rw data에는 접근을 하면 아직 memory에 rw data를 load도 하지 않은 상태일테니 쓰레기가 들어 있을 것입니다.
그래서 부트로더를 c로 작성한다면
*) dram controller를 초기화하고 stack pointer를 초기화할 때까지 stack사용 금지(function call금지, 과도한 local variable사용 금지)
*) rw data, zi data를 초기화 하기 전에 접근금지
를 해야 됩니다. compiler에 따라서는 #pragma를 덕지덕지 사용하면 회피가 가능한 경우도 있습니다만 종종 불가능한 경우도 있습니다.
예를 들어 부트로더가 특정 address부터 시작하고 부트로더 조금 뒤에 interrupt vector table이 있어야 되는데 부트로더를 c로 작성해서 stack사용을 하지 않기 위해서는 call을 못하는 상황이 발생하면 기술적으로 c로 작성하기가 불가능한 경우도 생기게 됩니다. assembly의 경우에는 이런 경우에 그냥 stack사용 안하고 멀리 다른 곳으로 jump해 버리면 해결이 되겠죠. :)
저는 주로 #pragma 묘기로 부트로더 작성이 가능한 경우에는 #pragma로 작성하고 불가능한 경우에는 c로 부트로더를 먼저 작성한 후에 disassemble을 해서 내용을 보고 assembly level에서 상황에 맞게 수정을 합니다.(예를 들어 stack에 접근하는 부분을 삭제)
c로 부트로더를 만들게 되면 또 하나 위험할 수가 있는 것이 optimize option을 주면 stack을 사용안 안하고 optimize option을 안주면 stack을 사용하는 경우도 있을 수가 있고, compiler가 버전업이 되면서 이전에 stack을 사용하지 않는 code를 생성하던 c 소스코드가 stack을 사용하는 code를 생성할 수도 있기 때문에 특정 compiler version의 특정 compile option을 지칭해서 이렇게 반드시 컴파일하라고 지시해야 됩니다.
cache라던가 mmu라던가 기타등등의 문제도 있지만 일단 저것들이 부트로더를 assembly로 많이 만드는 가장 큰 이유인 것으로 생각됩니다.
Taeho Oh ( ohhara@postech.edu , ohhara@plus.or.kr ) http://ohhara.sarang.net
Postech ( Pohang University of Science and Technology ) http://www.postech.edu
Digital Media Professionals Inc. http://www.dmprof.com
Taeho Oh ( ohhara@postech.edu ) http://ohhara.sarang.net
Postech ( Pohang University of Science and Technology ) http://www.postech.edu
Alticast Corp. http://www.alticast.com
댓글 달기