Dlaczego tworzenie 64-bitowej wersji programu może być trudne?

W moim krótkim programowaniu kompilowanie dowolnego C ++, Java itp. Na maszynie 32- lub 64-bitowej było banalne, o ile mam pełne źródło programu.

Ale wiele programów nie zostało wydanych 64-bitowych. Najbardziej denerwujące jest to, że nie ma jeszcze 64-bitowej wersji silnika Unity.

Co utrudnia kompilację niektórych programów dla komputerów 64-bitowych?

compiler 64-bit 32-bit

— calben
źródło

bo głupi programiści ciągle zakładająsizeof(int)==sizeof(void*)

— maniak ratchet

Najważniejszym powodem w naszym środowisku jest zależność od niektórych komponentów innych firm, które nie są dostępne w wersji 64-bitowej. Nie wiem, czy dotyczy to również Jedności, ale nie byłbym zbyt zdziwiony, gdyby tak było.

— Doc Brown

Mogą używać typedef jak int32, int64 dla int, float, pointer zamiast zakładać ich rozmiar. Co może rozwiązać wiele problemów. Wiele problemów zaczyna się od momentu, gdy zaczynamy zakładać.

— Kshitij

Co w rzeczywistości jest całkowicie uzasadnionym założeniem dotyczącym płaskich architektur. Windows umyślnie popełnił błąd, aby uniknąć zepsucia własnych błędów.

— Joshua

Dlaczego miałoby to być rozsądnym założeniem? Spodziewam mieć przyzwoity operator*za int, ale wskaźniki nie potrzebujemy. Ponadto większość środowisk Linux i Unix ma również int32 bity.

— MSalters

Odpowiedzi:

Ogólny problem polega na tym, że bardzo łatwo jest zakodować nieudokumentowane założenia w programie i bardzo trudno jest znaleźć miejsca, w których te założenia zostały przyjęte. Języki wysokiego poziomu w pewnym stopniu izolują nas od tych obaw, ale w językach niższego poziomu używanych do wdrażania platform i usług łatwo jest robić rzeczy, które niekoniecznie są przenośne w różnych architekturach:

Zakładając, że intjest wystarczająco duży, aby przechowywać wskaźnik
Zakładanie właściwości reprezentacji wskaźników, np. Do znakowania wskaźnika
Zakładając, że wskaźniki danych i wskaźniki kodu mają ten sam rozmiar

Istnieją również praktyczne obawy związane z zarządzaniem wersjami. Jeśli zrobię tylko wersję x86, nadal będzie działać na x86-64, choć być może wolniej z powodu ograniczonej dostępności rejestrów. Podczas gdy kompiluję zarówno dla x86, jak i x86-64, muszę teraz przetestować obie architektury i radzić sobie z błędami, które mogą wystąpić tylko w jednej architekturze, zwiększając koszt wysyłki nowej wersji.

— Jon Purdy
źródło

Zauważ, że można napisać błąd, który przejawia się tylko wtedy, gdy plik binarny x86 jest uruchamiany w 64-bitowej wersji systemu operacyjnego. Jest po prostu trudniej ;-)

— Steve Jessop

+1. Chciałbym dodać do punktu „zarządzanie wersjami”: jeśli moje oprogramowanie opiera się na komponentach innych firm, nawet jeśli dostępna jest wersja 32-bitowa i 64-bitowa konkretnego komponentu, dodatkowy wysiłek związany z testowaniem nowych wydań nie powinno być niedoceniane. Dlatego zarządzanie wydaniami IMHO powinno być pierwszym punktem na tej liście, a nie tylko notatką dodatkową.

— Doc Brown

Czy mógłbyś rozwinąć kwestię rozmiaru wskaźnika wewnętrznego? Czy to dlatego, że w środowisku 64-bitowym przestrzeń pamięci byłaby większa niż pozwala na to int?

— TankorSmash

@TankorSmash: normalnie na x86 sizeof(int) == sizeof(void *)(oba są 32-bitowe); na x86_64 normalne jest utrzymywanie int32 bitów (pozostaje kompatybilny z x86 i unika marnowania miejsca w pamięci), ale wskaźniki muszą być 64-bitowe (ponieważ wirtualna przestrzeń adresowa wzrasta do 2 ^ 64), więc nie mogą być dłużej wbity w intlub unsigned int.

— Matteo Italia

Większość oprogramowania będzie działać tak samo, jeśli zostanie skompilowane zarówno dla 32-bitowej, jak i 64-bitowej architektury Intel / AMD. Jednak niektóre oprogramowanie tego nie zrobi. Oprócz lenistwa lub docierania do większej liczby odbiorców istnieją pewne szczególne powody, dla których rekompilacja w wersji 64-bitowej nie będzie działać.

Oprogramowanie może wykorzystywać niebezpieczne operacje na wskaźnikach. Być może program wstawia wskaźnik do int, który jest zazwyczaj 32-bitowy dla większości kompilatorów C i C ++. Wskaźniki to 64 bity w 64-bitowym programie. To nie działa.
Operacje przesunięcia bitów mogą dawać różne wyniki, jeśli zastosowany typ liczby całkowitej ma inny rozmiar. Może to stanowić problem przy korzystaniu ze zwykłego typu danych zamiast standardowego typu typef, takiego jakint32_t
Typ danych używany w unii może zmieniać rozmiary, zmieniając zachowanie unii.
Oprogramowanie może polegać na bibliotekach tylko 32-bitowych. Ogólnie rzecz biorąc, program 64-bitowy będzie działał tylko z bibliotekami 64-bitowymi ze względu na założenia dotyczące stosu, wskaźników itp.

Trudność, o którą pytasz w swoim pytaniu, polega na tym, że w niektórych bazach kodu mogą znajdować się miliony wierszy kodu, które wykonują niebezpieczne operacje, dokonują niebezpiecznych założeń, mają skróty i sprytne „optymalizacje” wprowadzone przez programistów. Kod albo nie skompiluje się w środowisku 64-bitowym, albo skompiluje, ale będzie zawierał błędy show-stopper. Naprawienie wszystkich problemów może zająć dużo czasu. Być może firma naprawi je z czasem, dopóki nie będzie możliwe wydanie wersji 64-bitowej. Być może firma opracuje „wersję 2” wraz z aktualnymi wydaniami serwisowymi, ponieważ konieczne jest całkowite przepisanie.

Morał tej historii jest pisanie czystego kodu i nie próbowanie odgadywania kompilatora na nowo ani dodawania sprytnych optymalizacji, które nie są potrzebne, mogą uszkodzić oprogramowanie i prawdopodobnie i tak nie pomogą.

W tym artykule zawarto o wiele więcej szczegółów, niż mogłem się spodziewać w tej odpowiedzi: 20 problemów z przenoszeniem kodu C ++ na platformie 64-bitowej

— Tulains Córdova
źródło

Problemy mogą wykraczać poza samą kompilację; Mam muzułmańskiego przyjaciela, który nie może korzystać z dostępnego 64-bitowego FL Studio, ponieważ wymagają wielu VSTi, które są tylko 32-bitowe; inne architektury wtyczek opartych na łączach dynamicznych są podobnie dotknięte.

— StarWeaver,

Dzięki za edycję: Zazwyczaj jestem BARDZO wybredny pod względem gramatyki, ale popełniłem kilka błędów. I @StarWeaver Myślę, że dotknąłem tego, kiedy powiedziałem, że kod może się skompilować, ale zawierać błędy. To wciąż wraca do mojego punktu o pisaniu czystego kodu dla dowolnego języka i platformy, na którą celujesz.

„Mają błędy show-stoppera” Stopper show jest oczywisty i „na twoją twarz” i można sobie z nim poradzić. Myślę, że prawdopodobnie gorsze są wszystkie problemy, które powodują subtelnie niepoprawne wyniki, które pozostaną niezauważone przez długi czas.

— Burhan Ali,