빅엔디안, 리틀엔디안

'걸리버 여행기'에 나오는 소인국 릴리퍼트와 블레퍼스크는 달걀을 깰 때 뭉툭한 끝(big-end)으로 깨느냐 아니면 뾰족한 끝(little-end)으로 깨느냐의 문제로 전쟁을 한다.

바이트 순서

컴퓨터의 메모리와 같은 1차원 공간에서 바이트를 배열하는 순서를 바이트 오더(byte order)라고 하는데, 빅 엔디언(big-endian)은 사람이 숫자를 쓰는 방법과 같이 큰 단위의 바이트가 앞에 오는 방법이고, 리틀 엔디언(little-endian)은 반대로 작은 단위의 바이트가 앞에 오는 방법이다.

예를 들어, 0x1234를 빅엔디안에서는 12 34로 표현되고, 리틀엔디안에서는 34 12로 표현된다.

두 방법 중 어느 한 쪽이 다른 쪽과 비교해 압도적으로 좋거나 나쁘지는 않다고 알려져 있으며, 두 방법은 서로 다른 여러 아키텍처에서 서로 공존하고 있다. 그러나 x86 아키텍처가 리틀 엔디언을 쓰기 때문에, 오늘날 x86 아키텍처를 사용하는 대부분의 데스크톱 컴퓨터는 리틀 엔디언을 쓰며 이를 '인텔 포맷'이라 한다. 거꾸로 네트워크에서는 주소를 빅 엔디언으로 쓰는데, 역사적으로 라우팅이 전화를 거는 식으로 접두 부호로 이루어졌기 때문이다. 이의 영향으로 많은 프로토콜과 몇몇 파일 포맷이 빅 엔디언을 사용하고 있다. 모토로라 프로세서들은 일반적으로 빅 엔디언을 사용하며, ARM 프로세서들은 성능 향상을 위해 빅 엔디언과 리틀 엔디언을 선택할 수 있도록 되어 있다.

빅 엔디언은 소프트웨어의 디버그를 편하게 해 주는 경향이 있다. 사람이 숫자를 읽고 쓰는 방법과 같기 때문에 디버깅 과정에서 메모리의 값을 보기 편한데, 예를 들어 0x59654148은 빅 엔디언으로 59 65 41 48로 표현된다.

반대로 리틀 엔디언은 메모리에 저장된 값의 하위 바이트들만 사용할 때 별도의 계산이 필요 없다는 장점이 있다. 예를 들어, 32비트 숫자인 0x2A는 리틀 엔디언으로 표현하면 2A 00 00 00이 되는데, 이 표현에서 앞의 두 바이트 또는 한 바이트만 떼어 내면 하위 16비트 또는 8비트를 바로 얻을 수 있다. 반면 32비트 빅 엔디언 환경에서는 하위 16비트나 8비트 값을 얻기 위해서는 변수 주소에 2바이트 또는 3바이트를 더해야 한다. 보통 변수의 첫 바이트를 그 변수의 주소로 삼기 때문에 이런 성질은 종종 프로그래밍을 편하게 하는 반면, 리틀 엔디언 환경의 프로그래머가 빅 엔디언 환경에서 종종 실수를 일으키는 한 이유이기도 하다.

또한 가산기가 덧셈을 하는 과정은 LSB로부터 시작하여 자리 올림을 계산해야 하므로, 첫 번째 바이트가 LSB인 리틀 엔디언에서는 가산기 설계가 조금 더 단순해진다. 빅 엔디언에서는 가산기가 덧셈을 할때 마지막 바이트로부터 시작하여 첫 번째 바이트까지 역방향으로 진행해야 한다. 그러나 오늘날의 프로세서는 여러개의 바이트를 동시에 읽어들여 동시에 덧셈을 수행하는 구조를 갖고 있어 두 엔디언 사이에 사실상 차이가 없다.

비트 순서

비트 단위의 접근이 필요할 수 있으므로 바이트 순서가 아니라 비트 순서를 따질 수도 있으나, 여러 가지 이유로 비트 순서는 상대적으로 덜 중요하다. 보통 메모리의 접근은 바이트 단위로 이루어지기 때문에 비트 단위의 접근에는 별도의 연산 과정이 필요한데, 이러한 연산 자체가 비트 순서에 대해 잘 정의되어 있기 때문에 비트를 접근하는 방법은 아키텍처에 중립적이다. 

최상위 비트(MSB)부터 채우는 것을 최상위 비트 우선, 최하위 비트(LSB)부터 채우는 것을 최하위 비트 우선이라 한다.

http://ko.wikipedia.org/wiki/%EC%97%94%EB%94%94%EC%96%B8