Turbo-C
C++Builder  |  Delphi  |  FireMonkey  |  C/C++  |  Free Pascal  |  Firebird
볼랜드포럼 BorlandForum
 경고! 게시물 작성자의 사전 허락없는 메일주소 추출행위 절대 금지
터보-C 포럼
Q & A
FAQ
팁&트릭
강좌/문서
자료실
Lua 게시판
볼랜드포럼 홈
헤드라인 뉴스
IT 뉴스
공지사항
자유게시판
해피 브레이크
공동 프로젝트
구인/구직
회원 장터
건의사항
운영진 게시판
회원 메뉴
북마크
볼랜드포럼 광고 모집

C/C++ 강좌/문서
[18] 리틀엔디안,빅엔디안(3)
김재구 [knis001] 17646 읽음    2002-09-23 18:07
[바이트오더링(Byte Ordering)]

우습잖게도 바이트값들을 더 큰 단위(워드,롱워드,쿼드워드..)로 표현하는 것은 생각지도 않은 큰 차이를 가져옵니다.

사람들이 '엔디안'이라는 이슈로 이야기할때는 바로 '바이트순서'(Byte Ordering)를 문제삼는 것이라고 할 수 있습니다.

서로 다르게 바이트순서를 결정하는 32비트 프로세서를 생각해봅시다.
바이트는 아스키문자를 저장할 수 있는 8비트 한단위라는 것을 잊지맙시다. 그럼 서로 다른 32비트 프로세서가 똑같은 자료를 어떻게 표현하려 하는지를 보기로 하겠습니다.


Big Endian  -->     0        1          2          3

                             U        N         I           X

                             3        2         1           0   <-- Little Endian         


빅엔디안 프로세서가 데이타를 일정한방향으로 저장합니다. 문제는 그와 다른 프로세서가 그 데이타를 읽어들일 경우에 다른 순서로 정렬하려한다는 것입니다. 둘다 32비트 컴퓨터로 가정했을 경우(4바이트를 한단위로 처리하는),한 프로세서가 U-N-I-X라는 순서로 데이타를 쓸경우, 다른 프로세서는  X-I-N-U라는 순서로 읽어들입니다. 큰 문제가 아닐 수 없습니다.

  이런 성가신 문제가 처음 등장한 것은 16비트 프로세서였는데,이 경우 한 프로세서가 16비트
  단위를 한 단위로 해서 'UN' 'IX'를 쓸 경우에, 다른 프로세서는 'NU', 'XI'라는 짝으로 다시말해
  'NUXI'라는 조합을 읽어들입니다. 이것이 바로 유닉스 프로그래머들이 엔디안을 언급할경우에
  'NUXI 문제'라고 지칭하는 이유가 되는 것이죠.
  
이 문제는 단지 문자들에만 영향을 미치는 것은 아닙니다. 바이너리값에도 영향을 미치는데, 많은 값들은 바이트의 조합으로 표현됩니다. 한바이트는 0-255사이의 값을 가지고 있고, 두바이트가(16비트)가 하나의 값을 표현할 경우에는 0-65535(256x256)사이의 값을 가질 수 있습니다. 두바이트중에 한바이트는 'least significant'(하위바이트)라고해서 그대로의 값을 표현하고, 또 한바이트는 'most significant'(상위바이트)라고 해서 자신이 가진 값의 256배를 표현합니다. 가령 한 컴퓨터에서 상위바이트가 50이고 하위바이트가 10이라는 값을 가질경우, 그것이 의미하는 값은 50 x 256 + 10 = 12,810 이 됩니다. 그런데 다른 컴퓨터에서는 상위바이트가 10,하위바이트가 50이 되어 10x256 +50=2,610을 의미하게 되는데 역시 문제가 아닐 수 없습니다.

MSB,LSB라는 것을 바이너리 오더링에서는 Most Significant Bit,Least Significant Bit이라고 했지만, 때로는 Most Significant Byte,Least Significant Byte를 말하기도 합니다. 표현의 문맥을 살펴서 어떤 의미로 쓰여졌는지를 잘 파악해야합니다.

바이트 오더링이 가장 극명하게 문제시되는 분야는 아마 네트웍통신과 파일호환의 문제에서 나타날 것입니다. 가령 맥킨토시에서 파일에 12/34(슬래쉬는 바이트의 구분을 나타냄)라는 값을 쓸경우에 파일에는 1234라고 순서대로 저장되는데, 이 파일을 ibm pc에서 읽어들일 경우에는 34/12라는 값으로 읽어들여서 엉뚱한 값으로 변환되어버립니다. (한바이트 내부의 표현은 대부분 동일하다고 이미 바이너리 오더링 편에서 밝혔습니다.) 이 문제는 응용프로그램의 호환성에도 많은 영향을 미치는데, 이 때문에 파일의 저장형식을 표준화하는 문제가 제기되는 것입니다.

네트웍의 자료교환을 예로 들자면,C의 함수중에는 ntohs,htons,ntohl,htonl등의 바이트 스왑명령어가 존재합니다. 네트웍은 네트웍 바이트 오더링이라고 해서 자료교환의 순서를 표준화했는데, 빅엔디안의 방식에 따릅니다. ibm pc는 리틀엔디안이므로 자료를 보낼때도 바이트 순서를 바꿔야하고, 받을때에도 순서를 바꿔서 해석해야합니다. 단 바이트단위의 전송에는 해당하지 않습니다.

바이트 오더링(엔디안)의 문제에 있어서 현실적이고 단일한 해결방안은 존재하지 않습니다. 서로의 방식을 인정하고 그에 따라 변환하는 수밖에는 딱히 뾰족한 방책이 없지요.

     PowerPC같은 프로세서는 'Bi Endian'이라 불리는데,설정에 따라서 빅엔디안도 될 수있고,
     리틀엔디안도 될수 있는 프로세서입니다. 하지만 OS는 통상 하나의 엔디안에 의존하게 되므로
     동시에 두가지의 엔디안을 쓴다는 것은 큰 의미가 없습니다.

     인텔(x86)은 리틀엔디안, 모토롤라(68000's)는 빅엔디안입니다. 맥OS는 빅엔디안, Windows는
     리틀엔디안입니다.


-----------
원래는 한편 더써야겠지만,별로 중요치않은 내용이 있어서 그것을 빼느라 3편만으로 끝을 내야겠군요.

+ -

관련 글 리스트
18 리틀엔디안,빅엔디안(3) 김재구 17646 2002/09/23
Google
Copyright © 1999-2015, borlandforum.com. All right reserved.