Por que pode ser difícil criar uma versão de 64 bits de um programa?

No meu curto período de programação, foi trivial compilar qualquer um dos meus C ++, Java etc. para uma máquina de 32 ou 64 bits, desde que eu tenha a fonte completa do programa.

Mas um monte de software não é lançado de 64 bits. O mais irritante é que ainda não há uma versão de 64 bits do mecanismo Unity.

O que torna difícil compilar alguns programas para máquinas de 64 bits?

compiler 64-bit 32-bit

— Calben
fonte

porque os programadores estúpidos manter assumindosizeof(int)==sizeof(void*)

— aberração catraca

O principal motivo em nosso ambiente é a dependência de alguns componentes de terceiros que não estão disponíveis como 64 bits. Não sei se isso também se aplica à Unity, mas eu não ficaria muito surpreso se esse fosse o caso.

— Doc Brown

Eles podem usar typedef como int32, int64 para int, float, ponteiro, em vez de assumir o tamanho. O que pode resolver muitos problemas. Muitos dos problemas começam a partir do momento em que começamos a assumir.

— Kshitij

O que é de fato uma suposição perfeitamente razoável em arquiteturas planas. O Windows errou deliberadamente para evitar que eles estraguassem.

— Joshua

Por que isso seria uma suposição razoável? Eu esperaria ter um decente operator*para int, mas ponteiros não precisa disso. Além disso, a maioria dos ambientes Linux e Unix também possui int32 bits.

— MSalters

Respostas:

O problema geral é que é muito fácil codificar suposições não documentadas em um programa e muito difícil encontrar locais onde essas suposições foram feitas. As linguagens de alto nível tendem a nos isolar um pouco dessas preocupações, mas nas linguagens de nível inferior usadas para implementar plataformas e serviços, é fácil fazer coisas que não são necessariamente portáteis nas arquiteturas:

Supondo que intseja grande o suficiente para armazenar um ponteiro
Assumindo propriedades da representação de ponteiros, por exemplo, para marcação de ponteiro
Supondo que ponteiros de dados e ponteiros de código tenham o mesmo tamanho

Há também a preocupação prática do gerenciamento de versões. Se eu fizer apenas uma compilação do x86, ele ainda será executado no x86-64, embora talvez mais devagar devido à disponibilidade limitada de registros. Considerando que, se eu construir para x86 e x86-64, agora devo testar as duas arquiteturas e lidar com os bugs que podem surgir apenas em uma arquitetura, aumentando o custo de envio de uma nova versão.

— Jon Purdy
fonte

Observe que é possível escrever um bug que só se manifesta quando um binário x86 é executado na versão de 64 bits do sistema operacional. É apenas mais difícil ;-)

— Steve Jessop

+1. Gostaria de acrescentar o seguinte ao ponto de "gerenciamento de versão": se meu software depende de componentes de terceiros, mesmo se houver uma versão de 32 e 64 bits de um componente específico disponível, o esforço adicional para testar novas versões não deve ser subestimado. Portanto, o gerenciamento de liberações do IMHO deve ser o primeiro ponto dessa lista, não apenas uma nota lateral.

— Doc Brown

Você poderia elaborar sobre a questão do tamanho do ponteiro int? É porque em um ambiente de 64 bits, o espaço de memória seria maior do que o que um int permite?

— precisa saber é o seguinte

@TankorSmash: no x86 normalmente sizeof(int) == sizeof(void *)(ambos são 32 bits); em x86_64, é normal manter int32 bits (permanece compatível com x86 e evita desperdício de espaço na memória), mas os ponteiros precisam ter 64 bits (já que o espaço de endereço virtual chega a 2 ^ 64), para que não possam mais empurrado para um intou unsigned int.

— Matteo Italia

A maioria dos softwares funcionará da mesma maneira quando compilada para as arquiteturas Intel / AMD de 32 e 64 bits. No entanto, alguns softwares não. Além da preguiça ou do alcance de um público maior, existem algumas razões específicas pelas quais a recompilação como 64 bits não funcionará.

O software pode usar operações de ponteiro inseguras. Talvez um programa coloque um ponteiro em um int, que geralmente é de 32 bits para a maioria dos compiladores C e C ++. Os ponteiros são de 64 bits em um programa de 64 bits. Isso não funciona.
As operações de deslocamento de bits podem produzir resultados diferentes se o tipo inteiro usado for de tamanho diferente. Isso pode ser um problema ao usar um tipo de dados regular em vez de um typedef padrão, comoint32_t
Um tipo de dados usado em uma união pode mudar de tamanho, alterando o comportamento da união.
O software pode depender de bibliotecas apenas de 32 bits. Em geral, um programa de 64 bits funcionará apenas com bibliotecas de 64 bits devido a suposições sobre a pilha, ponteiros etc.

A dificuldade que você pergunta na sua pergunta é simplesmente que, em algumas bases de código, pode haver milhões de linhas de código que executam operações inseguras, fazem suposições inseguras, têm atalhos e "otimizações" inteligentes colocadas pelos desenvolvedores. O código não será compilado em um ambiente de 64 bits ou será compilado, mas terá erros de interrupção de exibição. Pode levar muito tempo para corrigir todos os problemas. Talvez uma empresa os conserte ao longo do tempo até que seja possível lançar uma versão de 64 bits. Talvez uma empresa desenvolva uma "versão 2" juntamente com os lançamentos de manutenção atuais, porque é necessária uma reescrita total.

A moral da história é escrever um código limpo e não tentar adivinhar o compilador ou adicionar otimizações inteligentes que não são necessárias, podem interromper o software e, provavelmente, não ajudarão.

Este artigo apresenta muito mais detalhes do que eu poderia incluir nesta resposta: 20 questões sobre como portar código C ++ na plataforma de 64 bits

— Tulains Córdova
fonte

Os problemas também podem ir além da compilação; Eu tenho um amigo músico que não pode usar o FL Studio de 64 bits disponível porque eles exigem muitos VSTi de apenas 32 bits; outras arquiteturas de plug-in baseadas em vínculo dinâmico são afetadas de forma semelhante.

— StarWeaver

Obrigado pela edição: normalmente sou muito exigente quanto à gramática, mas cometi alguns erros. E no StarWeaver, acho que toquei nisso quando disse que o código poderia ser compilado, mas tem bugs. Isso ainda remonta ao meu argumento sobre escrever código limpo para qualquer idioma e plataforma que você esteja alvejando.

"tem bugs de rolha de show" A rolha de show é óbvia e "na sua cara" e pode ser tratada. O que eu acho que provavelmente é pior são todos os problemas que produzem resultados sutilmente incorretos que passam despercebidos por um longo tempo.

— precisa