64비트 프로그램 개발들은 어떻게 하시나요?

ftfuture의 이미지

요즘 서버들도 64비트가 대세인거 같고요..
요즘 64비트로 개발을 하시는 분들은
기존 32비트 프로그램 하시다가 어떤 부분이 달라지나요..
리눅스 개발환경에서요..
기존 32비트로 된 프로그램을 64비트로 옮길려는데요..
작업하셨던 경험을 듣고 싶습니다.. :)

-m64라는 gcc옵션주는거랑 스트럭쳐 사이즈 계산하는거 그리고 또 어디를 신경써 주어야 할까요?

찾아봤는데.. 이문서가 괞찬네요..
http://jacking75.cafe24.com/Network/Unix_Linux/l-port64.htm

Necromancer의 이미지

기본 변수와 크기가 달라지죠.
gcc의 경우 long이 크기가 달라질겁니다.
그리고 포인터도 64비트로 바뀝니다.

기본 변수크기가 달라지는게 뭐 대수냐라고 생각할수도 있겠지만
이들이 구조체를 이루고, 또 이 구조체가 네트웍을 통해 전달되거나,
파일에 직접 쓰여질 경우 기존 32비트와 자료구조가 호환이 안돼서
많은 문제가 야기될 수가 있죠.

Written By the Black Knight of Destruction

Written By the Black Knight of Destruction

jacojang의 이미지

아마 대부분의 코드는 그대로 사용이 가능할것으로 보이고 변수의 크기에 관한 부분이 가장 문제가 될거 같네요..
제가 현재 32bit 와 64bit 에서 모두 동작하는 프로그램을 만들고 있는데...
아래와 같은 실수를 한적이 있습니다. ( 참고 하시기 바랍니다. )

-- CRC32 를 계산하는 부분 이었는데..
unsigned long crc32value;
char buf[4];
.....중략....
crc32value = *(unsigned long *)buf;

unsigned long 이 4byte 일때는 정확히 동작하는데...
64bit 에서 메모리 상황에 따라 다르게 나오더군요..( 당연히 그렇겠죠... long 이 8byte 이니...-.-)
unsigned long 을 u_int32_t 로 변경해서 수정했습니다.. ^^;

이런 부분이 없는지 잘 찾아 보기시 바랍니다...

--------------------------------------------------
http://www.jacojang.com

cppig1995의 이미지

uint32_t 아니었나요? -_-&

Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.

jacojang의 이미지

sys/types.h 에 보면 u_int32_t 로 typedef 되어 있습니다.
그래서 그걸 사용한거죠... ^^;

--------------------------------------------------
http://www.jacojang.com

cppig1995의 이미지

ISO/IEC 9899:1999(약칭 'C99') 표준에 의하면,
stdint.h 혹은 inttype.h에서는 [u]intN_t나 [u]intmax_t 형을 지원합니다.
그 외 이런 형을 편리하게 사용하기 위한 많은 다른 것들도 정의하고 있습니다.
(예: printf/scanf류의 표준 입출력 함수에서 사용하기 위한 형식지정자format specifier)
------------------------------------------------------
[낡배밀] 낡은 리눅스 배포판을 밀어내야 한다고 생각합니다.

Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.

only2sea의 이미지

가장 중요한 것이 포인터의 크기가 달라진다는 것이 아닐까 합니다. 덕분에 주소 공간이 넓어지는 것이 큰 이점이겠죠. 64비트 환경이라도 int는 32비트일 수도 있고 64비트 일 수도 있으므로, 32비트 환경에서 int와 포인터 형 간에 마구 형 변환을 한다거나 하는 코드를 64비트로 이식해 오면 warning이 마구 뜨거나 할 겁니다. 그리고 구조체의 크기가 달라질 수 있으므로 서로간에 통신을 하거나 파일에 저장할 때 쓰는 구조체의 경우에 신경을 쓰셔야 할 것 같습니다.

저는 long은 32비트 고정, long long은 64비트 고정이라고 알고 있었는데 연결해 주신 문서를 보니 long이 64비트인 경우도 있을 수 있네요.

결과 어셈 코드가 많이 달라지겠죠. 명령어 뒤에 l이 붙는게 아니라 q가 붙게 되겠구요.

뭔가 주저리주저리 써 보려 했지만 오히려 연결해주신 문서에서 많이 배우게 되네요. :)

아마록에서 가사와 앨범 표지를... http://kldp.net/projects/amarok-script/ 블로그: http://turtleforward.blogspot.com

죠커의 이미지

크기가 달라질 수도 있고 아닐 수도 있스비다. only2sea님의 말처럼 int가 64비트와 32비트 모드 두가지가 모두 존재합니다.
- CN의 낙서장 / HanIRC:#CN

cppig1995의 이미지

제 개인적인 생각이지만, 만약 64비트 시대에 C 자료형을 설계하고,
각 자료형이 차지하는 비트 수를 확정(현재의 C언어 표준은 이렇지 않죠)했다면...
short short: 16비트, short: 32비트, int/long/포인터: 64비트, long long: 128비트
이 정도가 되지 않았을까 싶습니다.
(SSE를 통해 128비트 정수 처리가 가능하다고 들은 것 같기도 한데요...)
------------------------------------------------------
[낡배밀] 낡은 리눅스 배포판을 밀어내야 한다고 생각합니다.

Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.

cppig1995의 이미지

가만히 생각해 보니까 어셈블리에서...

(만들고 있는 운영체제의 키보드 인터럽트 서비스 루틴에서 한 줄)
제가 사용하는 nasm의 인텔 문법: mov word [kb_shiftstate], ax
위를 변환한 GNU Assembler의 AT&T 문법: movw ax, [kb_shiftstate] (안써봐서... 맞나?)

이렇게 사용을 하는데요. 워드가 16비트라는 것도 잘못된 생각 아닌가요?
64비트 시스템에서 워드는 마땅히 64비트여야 한다고 생각합니다.
차라리 AMD 문서처럼 (1바이트 != 8비트지만) twobyte, fourbyte, eightbyte, sixteenbyte가
훨씬 더 나은 표기방식이라고 생각하고 있습니다.

(AMD64 Architecture Programmers Guide Volume 2를 보고 운영체제 만들고 있습니다.)
------------------------------------------------------
[낡배밀] 낡은 리눅스 배포판을 밀어내야 한다고 생각합니다.

Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.

Necromancer의 이미지

C언어는 그래도 표준이 있지
어셈블리 언어는 표준 자체가 없습니다.

어셈블러를 만든 사람이 그렇게 정한것이죠.

Written By the Black Knight of Destruction

Written By the Black Knight of Destruction

익명입니다의 이미지