64 비트 버전의 프로그램을 만드는 것이 왜 어려울 수 있습니까?

짧은 시간의 프로그래밍에서는 프로그램의 전체 소스가있는 한 32 비트 또는 64 비트 컴퓨터에서 C ++, Java 등을 컴파일하는 것이 쉽지 않습니다.

그러나 많은 소프트웨어가 64 비트로 출시되지 않았습니다. 가장 귀찮게도 아직 Unity 엔진의 64 비트 릴리스가 없습니다.

64 비트 시스템 용으로 일부 프로그램을 컴파일하기 어려운 이유는 무엇입니까?

compiler 64-bit 32-bit

— 칼벤
소스

바보 같은 프로그래머들이 계속 가정하기 때문에sizeof(int)==sizeof(void*)

— 래칫 괴물

우리 환경에서 가장 큰 이유는 64 비트로 사용할 수없는 일부 타사 구성 요소에 의존하기 때문입니다. 그것이 Unity에도 적용되는지는 모르지만, 그 경우에 너무 놀라지 않을 것입니다.

— Doc Brown

크기를 가정하는 대신 int, float, pointer에 int32, int64와 같은 typedef를 사용할 수 있습니다. 많은 문제를 해결할 수 있습니다. 가정을 시작한 시점부터 많은 문제가 시작됩니다.

— Kshitij

실제로 평면 아키텍처에 대한 완벽한 합리적 가정입니다. Windows는 자신의 실수를 피하기 위해 고의적으로 잘못했습니다.

— Joshua

왜 이것이 합리적인 가정일까요? 나는 괜찮은 가지고 기대 operator*를 들어 int,하지만 포인터는 필요하지 않습니다. 또한 대부분의 Linux 및 Unix 환경에도 int32 비트가 있습니다.

— MSalters

답변:

일반적인 문제는 프로그램에서 문서화되지 않은 가정을 인코딩하는 것이 매우 쉽고 그러한 가정이 이루어진 장소를 찾는 것이 매우 어렵다는 것입니다. 고급 언어는 이러한 우려로부터 우리를 격리시키는 경향이 있지만, 플랫폼과 서비스를 구현하는 데 사용되는 하위 언어에서는 아키텍처 전체에서 반드시 이식 가능하지 않은 작업을 쉽게 수행 할 수 있습니다.

int포인터를 저장하기에 충분히 크다고 가정
예를 들어 포인터 태그 지정을 위한 포인터 표현의 속성 가정
데이터 포인터와 코드 포인터의 크기가 같다고 가정

릴리스 관리에는 실질적인 문제도 있습니다. x86 빌드 만 만들면 레지스터의 가용성이 제한되어 있기 때문에 x86-64에서 계속 실행됩니다. x86과 x86-64를 모두 빌드하는 경우 이제 두 아키텍처를 모두 테스트하고 하나의 아키텍처에서만 발생할 수있는 버그를 처리하여 새 릴리스의 배송 비용을 증가시켜야합니다.

— 존 퍼디
소스

x86 바이너리가 64 비트 버전의 OS에서 실행될 때만 나타나는 버그를 작성할 수 있습니다. 그것은 ;-) 단지 단단

— 스티브 Jessop

+1. "릴리스 관리"지점에 다음을 추가하고 싶습니다. 소프트웨어가 타사 구성 요소에 의존하는 경우 사용 가능한 특정 구성 요소의 32 비트 및 64 비트 버전이 있어도 새로운 릴리스 테스트를위한 추가 노력 과소 평가해서는 안됩니다. 따라서 IMHO 릴리스 관리는 단순한 참고 사항이 아니라 해당 목록 의 첫 번째 지점 이어야합니다 .

— Doc Brown

int 포인터 크기 문제에 대해 자세히 설명해 주시겠습니까? 64 비트 환경에서 메모리 공간이 int가 허용하는 것보다 높기 때문입니까?

— TankorSmash

@TankorSmash : x86에서 정상적으로 sizeof(int) == sizeof(void *)(둘 다 32 비트 임); x86_64에서는 int32 비트 를 유지하는 것이 일반적 이며 (x86과 호환되며 메모리의 공간 낭비를 피함) 포인터는 64 비트 여야합니다 (가상 주소 공간이 최대 2 ^ 64이므로). int또는 로 밀었습니다 unsigned int.

— Matteo Italia

대부분의 소프트웨어는 32 비트 및 64 비트 Intel / AMD 아키텍처 용으로 컴파일 할 때 동일하게 작동합니다. 그러나 일부 소프트웨어는 그렇지 않습니다. 게으름이나 더 많은 청중에게 도달하는 것 외에도 64 비트로 다시 컴파일하는 것이 효과가없는 몇 가지 이유가 있습니다.

소프트웨어가 안전하지 않은 포인터 작업을 사용할 수 있습니다. 아마도 프로그램은 포인터를 int에 넣습니다. 대부분의 C 및 C ++ 컴파일러의 경우 일반적으로 32 비트입니다. 포인터는 64 비트 프로그램에서 64 비트입니다. 작동하지 않습니다.
사용되는 정수 유형이 다른 크기 인 경우 비트 시프트 연산은 다른 결과를 생성 할 수 있습니다. 다음과 같은 표준 typedef 대신 일반 데이터 유형을 사용할 때 문제가 될 수 있습니다.int32_t
공용체에 사용 된 데이터 형식은 크기를 변경하여 공용체의 동작을 변경할 수 있습니다.
소프트웨어는 32 비트 라이브러리에만 의존 할 수 있습니다. 일반적으로 64 비트 프로그램은 스택, 포인터 등에 대한 가정으로 인해 64 비트 라이브러리에서만 작동합니다.

귀하의 질문에 대한 어려움은 단순히 일부 코드 기반에는 안전하지 않은 작업을 수행하고 안전하지 않은 가정을 수행하며 지름길을 가지며 개발자가 영리한 "최적화"를 수행하는 수백만 줄의 코드가있을 수 있다는 것입니다. 이 코드는 64 비트 환경에서 컴파일되지 않거나 컴파일되지만 쇼 스토퍼 버그가 있습니다. 모든 문제를 해결하는 데 시간이 오래 걸릴 수 있습니다. 회사는 64 비트 버전을 출시 할 수있을 때까지 시간이 지남에 따라이를 고칠 것입니다. 전체 재 작성이 필요하기 때문에 회사는 현재 유지 보수 릴리스와 함께 "버전 2"를 개발할 것입니다.

이야기의 교훈은 깨끗한 코드를 작성하고 컴파일러를 추측하거나 필요하지 않은 영리한 최적화를 추가하지 않고 소프트웨어를 손상시킬 수 있으며 어쨌든 도움이되지 않는 것입니다.

이 기사는이 답변에 포함시킬 수있는 것보다 훨씬 자세하게 설명합니다 .64 비트 플랫폼에서 C ++ 코드를 이식하는 20 가지 문제

— 툴 린즈 코르도바
소스

이 문제는 단순한 컴파일 그 이상일 수도 있습니다. 32 비트에 불과한 많은 VSTi가 필요하기 때문에 사용 가능한 64 비트 FL Studio를 사용할 수없는 muscian 친구가 있습니다. 다른 동적 링크 기반 플러그인 아키텍처도 비슷한 영향을받습니다.

— StarWeaver

편집 해 주셔서 감사합니다. 나는 일반적으로 문법에 대해 매우 까다 롭지 만 몇 가지 실수를 저질렀습니다. 그리고 @StarWeaver 나는 코드가 컴파일 될 수 있지만 버그가 있다고 말할 때 그것에 대해 생각했습니다. 이것은 여전히 당신이 목표로하는 언어와 플랫폼에 맞는 깨끗한 코드를 작성하는 것에 관한 요점으로 돌아갑니다.

"쇼 스토퍼 버그가 있습니다"쇼 스토퍼는 명백하고 "당신의 얼굴에"처리 할 수 있습니다. 내가 더 나쁘게 생각하는 것은 오랫동안 눈에 띄지 않을 정도로 미묘하게 잘못된 결과를 생성하는 모든 문제입니다.

— Burhan Ali