endian 과 static , heap 영역과의 관계???
글쓴이: 하하 / 작성시간: 금, 2003/11/14 - 2:01오후
아래 코드를 보면 solaris , AIX 같은 경우
int main(void) { int val; char *ptr; ptr = (char*)&val; val = 0x89ABCDEF; printf("%X.%X.%X.%X\n", ptr[0], ptr[1], ptr[2], ptr[3]); exit(0); }
아래와 같이.
FFFFFFEF.FFFFFFCD.FFFFFFAB.FFFFFF89 (Little endian)
Linux 일 경우
FFFFFF89.FFFFFFAB.FFFFFFCD.FFFFFFEF (big endian)
이와 같이 찍힘니다.
제가 묻고 싶은건..... 이건 static 영역에 집어넣을때 endian
문제가 발생한다고 생각하는데..
그렇담 아래 코드와 같이 heap 이나 static 영역에 데이터를
넣을땐.. endian 문제는 발생하지 않고 AIX나 Linux나 동일한
값을 출력합니다. ...... 제 생각이 맞는지 의견을 듣고 싶습니다.
int main() { char *chr1; char *chr2; chr1 = "89ABCDEF"; <--- static 영역에 위치한다. chr2 = (char*)malloc(sizeof("89ABCDEF")); <--- heap 영역에 위치한다. strcpy(chr2, "89ABCDED"); printf("%c.%c.%c.%c\n", chr1[0], chr1[1], chr1[2], chr1[3]); printf("%c.%c.%c.%c\n", chr2[0], chr2[1], chr2[2], chr2[3]); exit(0); }
이 코드를 보면 출력이..
AIX , Linux 동일하게..
8.9.A.B
8.9.A.B
이렇게 출력됩니다...
제 생각이 맞다면..... static, heap은 무조건 bigendian
stack 은 머신에 따라.. Little 또는 big endian 채택....
그렇다면.. 왜 그런지.. ..... ... ..... ^^;;;;;;;;;;;
Forums:
영역에 따라 다른 것 없습니다.위 코드의 결과는 사실이 아닌것같고
영역에 따라 다른 것 없습니다.
위 코드의 결과는 사실이 아닌것같고, 아래 코드는..
정수 를 할 당한 것이 아니어서 영역만 바뀐것이 아니군요...
다시 확인해보세요.
---
http://coolengineer.com
죄송합니다. 무슨 말이신지.. [quote]위 코드의 결과는 사실
죄송합니다. 무슨 말이신지..
실제로 돌려본 결과 입니다.
무슨 말씀이신지.. 좀 더 자세히 설명해 주시면..
감사하겠습니다.
“바람에게도 길은 있다. 나는 비로소 나의 길을 가느니. 길은 언제나 어디에나 있다.”
Re: endian 과 static , heap 영역과의 관계???
이 내용은 결과가 바뀌었습니다.
---
http://coolengineer.com
우선.. 첫번째 말씀 해주신 부분은 잘못 올린게 맞습니다.허나..
우선.. 첫번째 말씀 해주신 부분은 잘못 올린게 맞습니다.
허나..
제가 작성한 두번째 소스의 잘못된 부분을 조목조목 설명
해주시면 안되나요? ..... 확실히 알고 넘어가고 싶습니
다.. 그럼.. 부탁드리겠습니다.. 감사합니다.
“바람에게도 길은 있다. 나는 비로소 나의 길을 가느니. 길은 언제나 어디에나 있다.”
두번째 소스에서 무엇이 잘못되었다는거죠? 굳이 잘못된 걸 짚자면 질문 자
두번째 소스에서 무엇이 잘못되었다는거죠? 굳이 잘못된 걸 짚자면 질문 자체??
1 byte짜리 char의 배열은 어떤 엔디안에서건 똑같이 저장됩니다. 2 byte나 4byte짜리를 어떤 순서로 넣느냐가 endian 문제죠.
두번째 예제에서 char를 int로 바꿔야지 제대로 된 질문이 되는것 같
두번째 예제에서 char를 int로 바꿔야지 제대로 된 질문이 되는것 같네요.
말씀하신것중 heap 영역만 테스트 한다면,
이렇게 해야지 첫번째 예제와 두번째 예제가 비교될 수 있겠는데요..
하수가 잘못 집었다면 과감히 채찍을~
ps : linux뿐이 없어서 테스트는 못해봤습니다. :oops:
덧붙임 : 네트워크로 byte stream을 보내고, 양쪽 시스템의 endian이 맞지 않는 경우 int, short.. 등은 ntoi() 등으로 변화시키지만, char[32] 등을 바꾸지는 않잖아요..
[quote]char[32] 등을 바꾸지는 않잖아요..[/quot
^^.. 하나의 질문을 더 던져주셨네요..
정말 궁금합니다.. 오늘 하루.. 는 위.. 문제를
계속 생각해봐야 할듯 합니다.........
“바람에게도 길은 있다. 나는 비로소 나의 길을 가느니. 길은 언제나 어디에나 있다.”
두 예제간 변수 타입이 다릅니다
첫번째 예제에서는
val = 0x89ABCDEF;
였는데 두번째 예제에서는
chr1 = "89ABCDEF";
로 타입이 바뀌는 바람에 결과값이 다르게 나오는 것이죠.
한국 BSD 사용자 포럼
big endian little endian은 multiple byte
big endian little endian은 multiple byte number type에만 적용됩니다.
0x89ABCDEF는 숫자이고 "89ABCDEF"는 문자열인건 당연히 아시죠?
문자열엔 endian 적용이 안됩니다.
[quote]big endian little endian은 multi
우선 답변 주신 모든 분들께 감사 드립니다.
그렇다면 이래야 하는 이유가 있는건가요? multiple
byte number 에만 endian 문제가 있는 이유가?
^___^;;;;;;;
“바람에게도 길은 있다. 나는 비로소 나의 길을 가느니. 길은 언제나 어디에나 있다.”
그러게 말입니다... 아마 마이크로 프로세서가 개발되는 초창기까지 거슬러
그러게 말입니다... 아마 마이크로 프로세서가 개발되는 초창기까지 거슬러 올라가야겠군요.
CPU가 16bit register를 메모리에 저장할 때, 어떤 순서로 저장할지의 문제와 밀접한 것입니다. CPU의 저장 방식에 따라서, C의 데이터 형이 내부처리되니까요.
---
http://coolengineer.com
[quote="하하"]그렇다면 이래야 하는 이유가 있는건가요? mul
"endian 문제가 있는 이유"라면야 다른 분 말씀처럼 아키텍쳐 얘기까지 해야겠지만 (근데 저도 몰라요. 속시원한 답을 다른 분이 올려주시면 좋겠죠 ^^) ...
"multiple byte number 에만" endian 문제가 있는 이유를 묻는 것은...
"왜 순서란 게 둘 이상이 있을 때만 의미가 있는가"라는 것과 같지 않을까요??
좋은 하루 되세요!
[quote="raymundo"]"multiple byte number
정말 멋진 비유군요. ^^;
[quote]"multiple byte number 에만" endia
아 제말의 의미는 string 그러니깐 배열은 문제가 없는
데 mutiple byte number (int 같은) 것만 인가라 질
문 이었습니다...
위 글을 읽어보면 .. cpu에서 int 값을 조작하고
return 할때 메모리에 그렇게 놓기 때문이라 이해 했
습니다. 머 배열 같은 경우 메모리에 상주하고 있어
endian 문제가 없지 않나 생각 되어집니다. ^^....
“바람에게도 길은 있다. 나는 비로소 나의 길을 가느니. 길은 언제나 어디에나 있다.”
[quote="하하"][quote]"multiple byte numb
'배열'인 것이 중요한 게 아니라 'char' 란 게 중요한 거죠. :-)
배열이라 문제가 없는 게 아니라 char 타입이 1 byte 짜리라 문제가
없는 겁니다. 메모리 상주는 전혀 관계가 없다고 생각합니다. 다른 변수라고
메모리에 상주하지 않나요.
만일 int 의 배열이었다면 역시 엔디안 문제는 발생합니다. 물론 배열 전체의
순서가 달라지는 것이 아니라 배열의 각 원소 내에서 바이트 순서가 바뀌는
것이지만...
(아 물론, char 가 2 byte 이고 int 가 1 byte 만 사용하는 랭귀지라면
char 에만 endian 문제가 있고 int 에는 없었겠죠)
좋은 하루 되세요!
배열에는 그 자체의 순서가 존재합니다.즉 a[0] 가 a[1]보다
배열에는 그 자체의 순서가 존재합니다.
즉 a[0] 가 a[1]보다 앞이죠.
그런데 2 byte 이상을 차지하는 자료형에서는 어떤 순서가 제대로 된 순서일까요? 0xABCD 라는 2 byte짜리 수가 있을 때, 이걸 0xAB와 0xCD를 어느 순서로 배치하는게 제대로 된 순서냐는 겁니다. 0xAB를 먼저 쓰면 big endian, 0xCD를 먼저 쓰면 little endian입니다.
전교생을 한 줄로 세울 때에 우선 각 반 순서로 배치할 수는 있습니다. 그럼 각 반 안에서 어느 순서로 배치하느냐는거죠. 키가 큰 학생을 앞에 세울 수도, 키가 작은 학생을 앞에 세울 수도 있습니다.
[quote="하하"][quote]"multiple byte numb
하하 님께서 요점을 정확히 파악을 못하셔서 혼돈을 하시는것 같습니다.
이 문제의 요점은 배열이 아닙니다.
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 방식입니다.
왼손잡이 오른손잡이도 적당한 표현이 될런지요
왼손잡이 오른손잡이도 적당한 표현이 될런지요
울랄라~ 호기심 천국~!!
http://www.ezdoum.com
endian
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가 필요한 경우 항상 계산이 필요하죠..
@UX... Vnn~
달걀을 먹을 때 작은 쪽 (little endian) 을 깨먹는게 좋은가
달걀을 먹을 때 작은 쪽 (little endian) 을 깨먹는게 좋은가요, 큰 쪽
(big endian) 을 깨먹는게 좋은가요? :-) 옛날에 이것 때문에 전쟁이 난
적도 있었답니다. 물론, 소설 속 이야기지만...
큰 것을 작은 조각으로 나누는 경우에 "순서" 의 문제가 나올 수 있습니다.
그 중 byte order 를 의미하기 위해 주로 사용되는 endian 은, 여러 개의
byte 가 모여 하나의 의미를 갖는 것을 byte 단위로 나눌 때 어느 것이
먼저가 되는지를 나타내는 순서입니다.
각 byte order 방식은 나름대로의 장단점을 가지고 있다고 하지만 (예를
들어, little endian 은 type 의 확장에 유리하다(?)는 장점과, 잘못된
프로그램을 눈감아주는 단점(?)을 가지고 있습니다), 지금은 실질적인
장단점 보다는 그 전통과 하위 호환성 때문에 더 중요성을 갖는 것
같습니다.
물론, 당연한 이야기지만, 바이트를 순서를 가지며 비트 단위로 접근할
필요가 있을 때도 (C 의 비트 필드) 유사한 순서 (bit order) 가 중요
합니다. (물론, 이러한 사실이 메모리에 비트 단위의 물리적 접근을
허락함을 의미하지는 않습니다)
일반적으로, 한 환경에서 byte order 와 (비트 필드 선언 순서로서의) bit
order 는 일치하며 이것이 많은 프로그램이 하나의 매크로 값을 byte order
와 bit order 선택에 사용하는 이유입니다.
--
Jun, Woong (woong at gmail.com)
http://www.woong.org
byte ordering 문제에서, intel 계열의 cpu들은 inve
byte ordering 문제에서, intel 계열의 cpu들은 inverted word라는 표현을 사용합니다.
데이터를 word 단위로 다루게 되는 경우, 이 데이터를 register에서 memory로 적재하게 되면 또는 그 반대로 memory에서 register로 읽어 들이는 경우, 하위 byte와 상위 byte의 순서가 바뀌게 되어 inverted word라는 말을 사용했다고 합니다.
이는 intel 계열 assembly 관련 책자들의 앞 부분에서 항상 다루는 내용들입니다.
To be a rich
댓글 달기