개인적으로 오늘 더욱 확실히 알고 싶어 컴퓨터에 대한 기초를 자세히 공부하고 있는 도중 x64에 대한 궁금함이 몇몇 부분에 대해서 드는 것이 있었습니다. 사실 x64 라는 것을 맨 처음 AMD(Advanced Micro Devices)의 K8 Hammer 시리즈에서 나올때 부터 관심을 가지고 있었던 터라, 754소켓 플랫폼인 뉴캐슬당시 그 쪽 방향으로 업그레이드 하게 되었고, XP x64를 나오기 기다려, 데몬(Daemon)또한 x64버젼이 나오길 기다렸던 기억이 생생합니다.
그 당시 인상적인 기억으로는 32비트 XP 에서 기본 계산기로 50000! 명령어를 내렸을 때, 20초 걸렸던 것이 64비트 XP에서는 50000!에 대한 경과시간이 10초 내외였던 것이 있었습니다. 그로인해 당시 엄청난 성능적 이득이 있을것이라 생각하였지만 실질적으로 여러가지 복합적인 이유로 인해 그다지 성능적 이득이 없었던 현상이 있긴 했습니다.
나름대로 64비트에 대한 선망을 가지며 많은 자료를 찾아보고 했으나 지금 생각해보니 기초에 대한 많은 부분을 조사하지 못하고 그냥 무작정 열망했었던 것이 아닌가 하는 생각이 갑지가 들어서 자료를 찾아보게 되었습니다. 64비트 프로그래밍을 하기 위해 가장 쉽게 접할 수 있는 IDE는 아무리 생각해도 VS.net 2005, VS.net 2008이라고 할 수 있습니다. 물론 다른 컴파일러도 64비트 플랫폼 설정을 할 수 있고, 컴파일을 진행할 수 있지만 자료를 쉽게 찾을 수 있다고 생각하기 때문에 VS를 선택했습니다. VS.net 을 설치할 때 마다 x64 Compiler를 체크하여 설치하긴 했지만 실제 개인적으로 사용하기 위해 개발했던 유틸을 제외하고는 개발하여 배포한적이 없었습니다. 그 만큼 x64에 대한 관심이 부족하지 않았나라고 생각합니다.
64비트 프로그래밍에 대한 염두에 두어야할 점을 생각하면 다음과 같은 점이 있더군요.
한 번 찾은 자료를 정리해 보았는데, 보기보다 많은 차이점이 존재하는 군요. 특히 __int64 라는 것은 기존 x86 Legacy 코드들과의 소스레벨 호환성을 위해서가 아닌가 생각합니다. 기존 소스를 많이 변경해야 한다면 문제점이 많이 생길테니까요. 그래서 32비트에서도 WORD를 32비트로 지정하지 않고 DWORD를 추가함으로써 지원했던것이 이유가 아닐까 합니다.
개인적으로 특히 __fastcall을 통한 많은 성능 향상을 할 수 있을것 같네요.
그 당시 인상적인 기억으로는 32비트 XP 에서 기본 계산기로 50000! 명령어를 내렸을 때, 20초 걸렸던 것이 64비트 XP에서는 50000!에 대한 경과시간이 10초 내외였던 것이 있었습니다. 그로인해 당시 엄청난 성능적 이득이 있을것이라 생각하였지만 실질적으로 여러가지 복합적인 이유로 인해 그다지 성능적 이득이 없었던 현상이 있긴 했습니다.
나름대로 64비트에 대한 선망을 가지며 많은 자료를 찾아보고 했으나 지금 생각해보니 기초에 대한 많은 부분을 조사하지 못하고 그냥 무작정 열망했었던 것이 아닌가 하는 생각이 갑지가 들어서 자료를 찾아보게 되었습니다. 64비트 프로그래밍을 하기 위해 가장 쉽게 접할 수 있는 IDE는 아무리 생각해도 VS.net 2005, VS.net 2008이라고 할 수 있습니다. 물론 다른 컴파일러도 64비트 플랫폼 설정을 할 수 있고, 컴파일을 진행할 수 있지만 자료를 쉽게 찾을 수 있다고 생각하기 때문에 VS를 선택했습니다. VS.net 을 설치할 때 마다 x64 Compiler를 체크하여 설치하긴 했지만 실제 개인적으로 사용하기 위해 개발했던 유틸을 제외하고는 개발하여 배포한적이 없었습니다. 그 만큼 x64에 대한 관심이 부족하지 않았나라고 생각합니다.
64비트 프로그래밍에 대한 염두에 두어야할 점을 생각하면 다음과 같은 점이 있더군요.
1. int, long은 결코 64비트 값이 아닌점
일반적으로 흔히 한 컴퓨터가 한 번에 처리할 수 있는 용량을 워드라고 부르고, 그로인해 보통 생각하는 int형 데이터가 64비트에서는 64비트라고 생각하기 쉽습니다( 하지만 Windows 32비트 환경에서는 32비트 데이터를 DWORD라고 합니다 ). 물론 저도 아무것도 모를때는 막연히 그렇지 않을까라고 생각했습니다. 하지만 자료를 찾아보니 값 자체는 32비트의 값을 지니게 되고, 포인터는 64비트 값을 가지게 되는 점이 다르더 군요. 실질적으로 C코드 의 종류를 예를 든다면 sizeof(int *)형태의 값이 일반적인 4가 아니라 8이 나온다는 점입니다. 64비트 값은 VS.net 에서는 __int64로써 사용할 수 있습니다. 32비트에서도 사용가능합니다. 성능상의 차이는 있겠죠.
2. 표준에 대한 자료형 크기가 다르다.
size_t, time_t, ptrdiff_t에 대해서 알고 계신가요? 저 같은 경우 STL에서 주로 사용하던 것인데 보통 생각할 때 32비트 머신에서 사용하였으므로 그 크기는 32비트 자료형으로 알고 있었습니다. 하지만 64비트에서는 64비트 자료형으로 사용이 된다는 점입니다. 보통 생각하셔도 당연한 얘기가 될 수 있을지도 모르겠습니다. 포인터 자체가 64비트 자료형을 띄게 되는데, 위치 차이인 ptrdiff_t가 64비트가 아니라면 연산자체의 문제가 발생할 수 있지 않을까요^^? 그런데 time_t에 대해서는 약간 의문점이 듭니다.
3. time_t에 대해선..
time_t 자료형에 대해선 굳이 깊히 생각할 일이 없어보입니다. VS.net 에서는 비트 플랫폼과 상관없이 2005 이상이냐 이전이냐에 따라서 자료형의 크기가 달라지더군요. 이 전에서는 32비트 값을 사용하였으나 2005 이상에서는 64비트 값을 사용하게 되었답니다. 이유는 32비트 값을 사용하게 되면 UTC 타임으로 2038년 1월 19일 이후의 시간을 표시할 수 없기 때문이라고 하네요. 예전 Y2K버그 였던 밀레니엄 버그로 한창 떠들석 했던 것을 생각하면 당연한 것으로 보입니다.
4. 기본 함수 Calling Convention은 __fastcall.
x86과 x64에 대한 레지스터 차이를 아실지 모르겠습니다. 기존 존재하던 EAX, EBX, ECX, EDX, ESP, EBP, ESI, EDI 이 32비트 크기에서 64비트 크기로 확장됨과 더불어 Rxx 로 시작하는 일반적인 레지스터 R9, R10, R11, R12, R13, R14, R15가 추가 되었습니다. XMM 레지스터도 8개가 추가적으로 확장되었죠. 그런데 이런 레지스터를 놀리는 짓은 성능에 많은 제약을 가하는 꼴이 아닐까요^^? 그래서 기본적으로 많은 레지스터를 생각하는 것으로 __fastcall이 기본이 되지 않았을까 생각합니다.
일반적으로 흔히 한 컴퓨터가 한 번에 처리할 수 있는 용량을 워드라고 부르고, 그로인해 보통 생각하는 int형 데이터가 64비트에서는 64비트라고 생각하기 쉽습니다( 하지만 Windows 32비트 환경에서는 32비트 데이터를 DWORD라고 합니다 ). 물론 저도 아무것도 모를때는 막연히 그렇지 않을까라고 생각했습니다. 하지만 자료를 찾아보니 값 자체는 32비트의 값을 지니게 되고, 포인터는 64비트 값을 가지게 되는 점이 다르더 군요. 실질적으로 C코드 의 종류를 예를 든다면 sizeof(int *)형태의 값이 일반적인 4가 아니라 8이 나온다는 점입니다. 64비트 값은 VS.net 에서는 __int64로써 사용할 수 있습니다. 32비트에서도 사용가능합니다. 성능상의 차이는 있겠죠.
2. 표준에 대한 자료형 크기가 다르다.
size_t, time_t, ptrdiff_t에 대해서 알고 계신가요? 저 같은 경우 STL에서 주로 사용하던 것인데 보통 생각할 때 32비트 머신에서 사용하였으므로 그 크기는 32비트 자료형으로 알고 있었습니다. 하지만 64비트에서는 64비트 자료형으로 사용이 된다는 점입니다. 보통 생각하셔도 당연한 얘기가 될 수 있을지도 모르겠습니다. 포인터 자체가 64비트 자료형을 띄게 되는데, 위치 차이인 ptrdiff_t가 64비트가 아니라면 연산자체의 문제가 발생할 수 있지 않을까요^^? 그런데 time_t에 대해서는 약간 의문점이 듭니다.
3. time_t에 대해선..
time_t 자료형에 대해선 굳이 깊히 생각할 일이 없어보입니다. VS.net 에서는 비트 플랫폼과 상관없이 2005 이상이냐 이전이냐에 따라서 자료형의 크기가 달라지더군요. 이 전에서는 32비트 값을 사용하였으나 2005 이상에서는 64비트 값을 사용하게 되었답니다. 이유는 32비트 값을 사용하게 되면 UTC 타임으로 2038년 1월 19일 이후의 시간을 표시할 수 없기 때문이라고 하네요. 예전 Y2K버그 였던 밀레니엄 버그로 한창 떠들석 했던 것을 생각하면 당연한 것으로 보입니다.
4. 기본 함수 Calling Convention은 __fastcall.
x86과 x64에 대한 레지스터 차이를 아실지 모르겠습니다. 기존 존재하던 EAX, EBX, ECX, EDX, ESP, EBP, ESI, EDI 이 32비트 크기에서 64비트 크기로 확장됨과 더불어 Rxx 로 시작하는 일반적인 레지스터 R9, R10, R11, R12, R13, R14, R15가 추가 되었습니다. XMM 레지스터도 8개가 추가적으로 확장되었죠. 그런데 이런 레지스터를 놀리는 짓은 성능에 많은 제약을 가하는 꼴이 아닐까요^^? 그래서 기본적으로 많은 레지스터를 생각하는 것으로 __fastcall이 기본이 되지 않았을까 생각합니다.
5. 기본적인 레지스터 사용법을 숙지.
RAX - Volatile - Return Value Register
RCX - Volatile - Fisrt Integer Argument
RDX - Volatile - Second Integer Argument
R8 - Volatile - Third Integer Argument
R9 - Volatile - Fourth Integer Argument
XMM0-Volatile-First FP Argument
XMM1-Volatile-Second FP Argument
XMM2-Volatile-Third FP Argument
XMM3-Volatile-Fourth FP Argument
R11, R11등의 레지스터는 참조한 링크에서 다른 사용방법이 있으므로 참조를 해보세요^^. 기본적인 사용법만 적어봤습니다. 어셈블리어로 코드를 작성할 때 유용하겠네요.
6. 더이상의 Inline Assembly는 지원하지 않음
x86 C++ 프로그래밍을 할 당시는 __asm{} 과 같은 문법들로 inline assembly를 사용할 수 있었습니다. 그로인해 어셈블리 코드를 직접입력할 수 있었습니다. 그런데 x64에서는 지원을 하지 않는다고 합니다. 하지만 Intrinsic 함수들이 지원되죠. 이 함수들을 사용하면 이에 해당하는 Assembly 명령어들이 바로 직접삽입되게 됩니다. 이에 대한 내용은 아래 링크를 보시기 바랍니다^^.
http://msdn.microsoft.com/en-us/library/26td21ds.aspx
RAX - Volatile - Return Value Register
RCX - Volatile - Fisrt Integer Argument
RDX - Volatile - Second Integer Argument
R8 - Volatile - Third Integer Argument
R9 - Volatile - Fourth Integer Argument
XMM0-Volatile-First FP Argument
XMM1-Volatile-Second FP Argument
XMM2-Volatile-Third FP Argument
XMM3-Volatile-Fourth FP Argument
R11, R11등의 레지스터는 참조한 링크에서 다른 사용방법이 있으므로 참조를 해보세요^^. 기본적인 사용법만 적어봤습니다. 어셈블리어로 코드를 작성할 때 유용하겠네요.
6. 더이상의 Inline Assembly는 지원하지 않음
x86 C++ 프로그래밍을 할 당시는 __asm{} 과 같은 문법들로 inline assembly를 사용할 수 있었습니다. 그로인해 어셈블리 코드를 직접입력할 수 있었습니다. 그런데 x64에서는 지원을 하지 않는다고 합니다. 하지만 Intrinsic 함수들이 지원되죠. 이 함수들을 사용하면 이에 해당하는 Assembly 명령어들이 바로 직접삽입되게 됩니다. 이에 대한 내용은 아래 링크를 보시기 바랍니다^^.
http://msdn.microsoft.com/en-us/library/26td21ds.aspx
한 번 찾은 자료를 정리해 보았는데, 보기보다 많은 차이점이 존재하는 군요. 특히 __int64 라는 것은 기존 x86 Legacy 코드들과의 소스레벨 호환성을 위해서가 아닌가 생각합니다. 기존 소스를 많이 변경해야 한다면 문제점이 많이 생길테니까요. 그래서 32비트에서도 WORD를 32비트로 지정하지 않고 DWORD를 추가함으로써 지원했던것이 이유가 아닐까 합니다.
개인적으로 특히 __fastcall을 통한 많은 성능 향상을 할 수 있을것 같네요.
"Computer" 분류의 다른 글
| SSD( Solid State Disk ) 사용... (4) | 2008/09/23 |
| High Precision Event Timer - 그 것은 무엇인가?? (0) | 2008/02/20 |
TAG X64
댓글을 달아 주세요
오호~ 그려? 멋진데~ @0@)/~
-b
글 잘봤당 ㅎㅎ 쵝오 >ㅁ<
ㅋㅋ 아우 멋지긴용 후더럴
해석을 한 것 뿐인뎅 ㅋ
저도 덩달아 잘 봤습니다. 쵝오~ ^^/
하지만 실제로 언제 64비트 프로그래밍을 할지는 모르겠네요 ㅋㅋ 일단 지식만 쌓아둬야죠~
헛.. 감사합니다.
까마구 횽님 블로그에서 자주 뵙던 분이시네요~
학교 선배님이신걸로 알고 있습니다. 이제야 인사올립니다^^.
64비트 프로그래밍은 아마도 제가 생각할 때는 대용량 데이터를 취급하는 것에서 성능향상이 무척 크지 않을까 하네요.. ㅎㅎ
관리자만 볼 수 있는 댓글입니다.
넵^^. 환영입니다. 저도 정리한 것 뿐이거든요^^.