IT관련 지식들 2010. 3. 11. 12:14
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


-------------------------------------------------------------------------------------------------
다음은 kldp 사이트에서 endian에 대한 질문과 답변중에서 발췌한 것입니다.

>>
1 byte짜리 char의 배열은 어떤 엔디안에서건 똑같이 저장됩니다. 2 byte나 4byte짜리를 어떤 순서로 넣느냐가 endian 문제죠.

>>

big endian little endian은 multiple byte number type에만 적용됩니다.

0x89ABCDEF는 숫자이고 "89ABCDEF"는 문자열인건 당연히 아시죠? 문자열엔 endian 적용이 안됩니다.

<<

multiple byte number 에만 endian 문제가 있는 이유가?  string 그러니깐 배열은 문제가 없는데 mutiple byte number (int 같은) 것만 인가라 질문 이었습니다... 위 글을 읽어보면 .. cpu에서 int 값을 조작하고 return 할때 메모리에 그렇게 놓기 때문이라 이해 했

습니다. 머 배열 같은 경우 메모리에 상주하고 있어 endian 문제가 없지 않나 생각 되어집니다. ^^....

>>

아마 마이크로 프로세서가 개발되는 초창기까지 거슬러 올라가야겠군요.

CPU가 16bit register를 메모리에 저장할 때, 어떤 순서로 저장할지의 문제와 밀접한 것입니다. CPU의 저장 방식에 따라서, C의 데이터 형이 내부처리되니까요.

>>

'배열'인 것이 중요한 게 아니라 'char' 란 게 중요한 거죠. :-) 배열이라 문제가 없는 게 아니라 char 타입이 1 byte 짜리라 문제가
없는 겁니다. 메모리 상주는 전혀 관계가 없다고 생각합니다. 다른 변수라고 메모리에 상주하지 않나요.

만일 int 의 배열이었다면 역시 엔디안 문제는 발생합니다. 물론 배열 전체의 순서가 달라지는 것이 아니라 배열의 각 원소 내에서 바이트 순서가 바뀌는것이지만...

(아 물론, char 가 2 byte 이고 int 가 1 byte 만 사용하는 랭귀지라면 char 에만 endian 문제가 있고 int 에는 없었겠죠)

>>

이 문제의 요점은 배열이 아닙니다.

char a[] = {1, 2, 3};
short b[] = {1, 2, 3};
두개의 배열이 메모리에 어떻게 들어가는지 보면..
a[] 는 01 02 03 순서로 메모리에 들어가고
b[] 는 01 00 02 00 03 00 순서로 메모리에 들어가게 됩니다.
b[]경우를 눈여겨 보시면... short 형 1은 0001이지만... 0100으로 메모리에 들어가는걸 보실 수 있을껍니다.

이 문제의 요점은 배열이 아니고...CPU에서 한번에 액세스하는 데이터의 크기가 중요한 것입니다.

Intel CPU의 경우라면 AX, BX, CX, DX등의 16비트 레지스터를 통해 short형을 다루게 되는데 mov [...], AX 라는 명령이 있으면 AX레지스터의 내용을 메모리 ...에 넣게 되는데.. AX레지스터의 데이터의 크기가 16비트이기 때문에 16비트 데이터가 메모리에 들어갈 때 값의 순서가 바이트 단위로 역으로 바뀌게 됩니다.

그러니까.. 배열 이냐 아니냐는 아무런 상관이 없고...
char, short, int 등의 데이터 형이 문제가 되는 것입니다.

>>

덧붙여서 말씀드린다면, little endian, big endian은 하드웨어 차원의 문제입니다.
맨 처음 '하하'님께서 AIX, Solaris와 Linux 에서 다른 결과가 나온다고 하셨는데 잘못된 문제 제기라 할 수 있지요.
AIX나 Solaris라서가 아니라 거기서 사용하는 하드웨어(CPU)가 어떠한 방식으로 multi-byte data를 access하느냐에 따라서 little endian, big endian이 결정되는 것입니다.

따라서 운영체제에 따라서 결과가 틀려지는게 아닙니다. 만약 같은 하드웨어(intel CPU)에서 다른 운영체제(linux, windows 기타 등등)를 사용한다고 하더라도 동일한 endian 방식을 갖습니다.
반대로 동일한 linux라 하더라도 다른 방식의 하드웨어(intel 계열은 little endian, 모토롤라 계열은 big endian이죠)를 쓴다면 각기 다른 endian이 되어서 '하하'님께서 맨 처음 사용한 예제는 각기 다르게 나오겠죠.

다시 말씀드리면 endian 문제는 static이냐 heap, stack같은 메모리 사용방식이나 또는 운영체제에 따라 달라지는 것이 아니라 하드웨어 레벨에서 사용하는 multi byte order 방식입니다.

>>

multi byte일 때 byte단위로 addressing을 할 때, 시작이 어디인가가 문제입니다.

big-endian 계열의 경우 상위 byte가 하위 address로 저장되는 방식. 
즉 address가 커지면서 하위 byte 데이터가 저장됩니다. 
일반적으로 배열을 생각하시면 됩니다. a[0]보다는 a[1]의 address가 커지겠죠. 그래서 long 형에 저장된 순서나 char [4]에 저장된 순서가 같게 됩니다.

little-endian 계열의 경우는 상위 byte가 상위 address로 저장되는 방식.
즉 byte단위로 하위 byte 부터 address가 커지면서 상위 byte로 저장됩니다.
그래서 long형에 저장된 순서나 char[4]에 저장된 순서가 바뀌게 됩니다.

둘다 논리적인 설명으로는 타당한데, little-endian의 경우 intel에서 8bit에서 16bit로 넘어 오면서 8bit code를 재컴파일 없이 수행하기 위한 꽁수역활이 큰듯합니다. network byte order가 big-endian이죠 :)

little-endian의 경우 address를 읽을 때, 한 byte만 읽으면, 원래 저장되어 있던 값이 8bit이건 16bit이건 32bit이건 가장 최하위의 8bit값을 읽을 수 있습니다. big-endian의 경우는 address 부분이 항상 최상위 byte를 가르키고 있으므로 최하위 8bit가 필요한 경우 항상 계산이 필요하죠..

>>byte ordering 문제에서, intel 계열의 cpu들은 inverted word라는 표현을 사용합니다.

데이터를 word 단위로 다루게 되는 경우, 이 데이터를 register에서 memory로 적재하게 되면 또는 그 반대로 memory에서 register로 읽어 들이는 경우, 하위 byte와 상위 byte의 순서가 바뀌게 되어 inverted word라는 말을 사용했다고 합니다.

이는 intel 계열 assembly 관련 책자들의 앞 부분에서 항상 다루는 내용들입니다.


'IT관련 지식들' 카테고리의 다른 글

Carry 와 oVerflow  (2) 2010.03.11
ARM Architecture / ARM Core / ARM Processor  (1) 2010.03.11
Harvard architecture / Von-Neumann architecture  (0) 2010.03.11
CISC / RISC  (0) 2010.03.11
LDM, STM  (0) 2010.03.06
posted by 동글동글82
: