Byte order












Big endian 은 그림에서 보는 바와 같이 낮은 주소에 값의 높은 자리가 저장된다.
개념상으로는 Big endian 이 쉽다. 사람이 쓰는 순서대로 큰 단위가 먼저 온다.
Little endian 은 반대의 순서를 갖는다.


어느 것이 더 좋은가 ?

결론은 둘 다 장단점이 있다.
Big endian 은 임의 정수 타입의 부호를 알고 싶다면 타입의 크기에 관계 없이 첫 비트만 보면 된다.
그리고 수가 출력되는 순서대로 저장 되어 있다.

Little endian 은 하위 바이트만의 계산이 필요할 때 더 편하다고 한다.

관련 자료 :
http://www.cs.umass.edu/~verts/cs32/endian.html

다음 링크에는 이런 것들뿐만 아니라 bi endian, middle endian 도 설명한다.
(영문 버전이 더 자세히 설명되어 있는 것 같다 - 안 읽어 봤음 -_-)
http://ko.wikipedia.org/wiki/%EC%97%94%EB%94%94%EC%96%B8



잡담.

학교에 다닐 때는 대부분 한 가지 시스템에서 (아마도 인텔기반 pc와 windows)
프로그램 하므로 이런 것들을 신경 쓸 필요가 없었다.
어쨌든 어느 시스템에서건 일반 응용 프로그램을 공부하는 사람에겐 이런 개념이 사실 중요하지는 않다.
그냥 잘 돌아가기 때문에

인텔 x86 계열을 제외한 많은 시스템에서는 Big endian 을 사용하는데,
네트워크가 포함된 응용프로그램과 같은 프로젝트에서 종종 실수를 한다.
만약  Big endian 을 사용하는 ppc 계열 시스템에서 네트워크로 데이터를 아무 변경 없이 보내면 된다.
하지만 Little endian 상에서 프로그래밍 하면서 byte order 개념이 없으면
때론 무한 디버깅의 트랩으로 빠질 가능성이 농후 한다.
물론 같은 시스템에서만 통신한다면 다행히 이런 문제를 피할 수도 있지만 ... (이게 과연 다행인지)

네트워크 관련 프로젝트가 아니더라도 특정 파일 포멧을 읽어서 수행하는 소프트웨어를 만들 때에도
해당 파일이 어떤 byte order 로 저장 되었는 지 알아야 한다.
예를 들면 TTF 파일에서 데이터는 Big endian 으로 저장되어 있다.
처음 이 포멧을 분석하면서 쌩뚱맞은 입력이 들어와서 당황한 적이 있었는데,
바로 byte order 문제 였다. 다행히 이런 문제를 알고 있었기 때문에 쉽게 문제를 해결 할 수 있었다.

아무튼 옆 팀에서 윈도우즈에서 우리 제품을 broadcasting 하여 scanning 하는 소프트웨어를 만들었는데,
우연인지 서로 통신하는 양쪽 시스템이 모두 Little endian 을 사용하고 있었다.
그래서 그 사람은 그냥 아무 생각 없이 그냥 바이트 순서를 변경하지 않고 서로 통신하고 있었다.

나도 그런 류의 기능을 우리가 개발하는 제품에 넣으려고 했는데 ,
이미 만들어져 있는 코드가 있었기 때문에 짜증나게도 Big endian 을 사용하는 우리 시스템에서
일부러 Little endian 으로 변경하여 데이터를 주고 받도록 코딩하여야 했다.
그 쪽이 잘 못 된 거라고 그쪽에서 프로그램을 변경하도록 요구 했지만 -_- 통할리가 없다.
(나는 힘이 없다 -_-)

아무튼 이거 때문에 고생을 좀 했다. (헛갈려서...)

사실 Big endian 의 장점이 개념적으로 쉽다는 것인데,
잘 못된 선행 프로젝트 때문에 ... 그런 장점이 단점이 되어 버린 경우이다.
아마도 나중에 다시 이 얘기가 나오면 결국 Big endian 으로 통신하도록 바꿀 것이 틀림 없다.
그럴 걸 대비해서 함수 호출 하나로 쉽게 둘 다 지원할 수 있도록 해 놓긴 했다.
다른 사람 잘 못 때문에 내가 더 이상 삽질 할 수는 없지 -_-;;