Чому може бути складно зробити 64-бітну версію програми?

У моєму програмуванні за короткий час було тривіально збирати будь-яку з моїх C ++, Java і т. Д. Для 32 або 64-бітної машини, якщо я маю повне джерело для програми.

Але багато програмного забезпечення не випущено 64-бітним. Що найприємніше, ще немає 64-бітового випуску двигуна Unity.

Що ускладнює компіляцію деяких програм для 64-бітних машин?

compiler 64-bit 32-bit

— кальбен
джерело

тому що дурні програмісти продовжують припускатиsizeof(int)==sizeof(void*)

— храповий вирод

Найвища причина в нашому середовищі - залежність від сторонніх компонентів, які недоступні як 64 біт. Не знаю, чи це стосується і Єдності, але я б не надто здивувався, якщо це так.

— Док Браун

Вони можуть використовувати typedef, як int32, int64 для int, float, pointer, замість того, щоб вважати їх розмір. Що може вирішити багато проблем. Багато проблем починаються з того часу, коли ми починаємо вважати.

— Кшитій

Це насправді цілком розумне припущення щодо плоских архітектур. Windows помилково помилилася, щоб не зламати власні гвинти.

— Джошуа

Чому це було б розумним припущенням? Я б очікувати , щоб мати пристойний operator*для int, але покажчики не потрібно. Крім того, більшість середовищ Linux та Unix мають також int32 біти.

— MSalters

Відповіді:

Загальна проблема полягає в тому, що кодувати незадокументовані припущення в програмі дуже просто, і дуже важко знайти місця, де були зроблені ці припущення. Мови високого рівня, як правило, відштовхують нас від цих проблем, але мовами нижчого рівня, які використовуються для впровадження платформ і служб, легко робити речі, які не обов'язково переноситься в архітектурах:

Якщо припустити, що intдостатньо великий, щоб зберігати вказівник
Припускаючи властивості подання покажчиків, наприклад, для мітки покажчиків
Якщо припустити, що покажчики даних та покажчики коду мають однаковий розмір

Існує також практична проблема управління випусками. Якщо я зроблю лише збірку x86, вона все ще працюватиме на x86-64, хоча й може бути повільніше через обмеженість доступності регістрів. Якщо, якщо я будувати для x86 та x86-64, я повинен перевірити обидві архітектури та мати справу з помилками, які можуть виникнути лише в одній архітектурі, збільшуючи вартість доставки нового випуску.

— Джон Перді
джерело

Зауважте, що помилку можна записати лише тоді, коли бінарний x86 працює у 64-бітній версії ОС. Просто складніше ;-)

— Стів Джессоп

+1. Я хотів би додати наступне до пункту "управління випуском": якщо моє програмне забезпечення покладається на сторонні компоненти, навіть якщо доступна 32 та 64-бітна версія конкретного компонента, додаткові зусилля для тестування нових випусків не слід недооцінювати Тож управління випуском IMHO має стати першим пунктом у цьому списку, а не лише стороною.

— Док Браун

Чи можете ви детальніше розглянути питання про розмір вказівника? Це тому, що в 64-бітовому середовищі простір пам'яті був би більшим, ніж це дозволяє int?

— TankorSmash

@TankorSmash: на x86 зазвичай sizeof(int) == sizeof(void *)(вони обоє 32 бітні); на x86_64 нормально зберігати int32-бітний (він залишається сумісним з x86 і уникає витрачання місця в пам’яті), але покажчики повинні бути 64-бітовими (оскільки віртуальний адресний простір збільшується до 2 ^ 64), тому вони більше не можуть бути засунули в intабо unsigned int.

— Маттео Італія

Більшість програмного забезпечення буде працювати однаково при компіляції для 32-ти та 64-бітної архітектури Intel / AMD. Однак деяке програмне забезпечення не буде. Окрім лінощів чи досягнення більшої аудиторії, є деякі конкретні причини, чому перекомпіляція як 64-бітний не спрацює.

Програмне забезпечення може використовувати небезпечні операції вказівника. Можливо, програма ставить покажчик на int, який, як правило, становить 32 біт для більшості компіляторів C і C ++. Покажчики - це 64 біти в 64-бітній програмі. Це не працює.
Операції зсуву бітів можуть давати різні результати, якщо використовується цілочисельний тип іншого розміру. Це може бути проблемою при використанні звичайного типу даних замість стандартного typedef, такого якint32_t
Тип даних, що використовується в об'єднанні, може змінювати розміри, змінюючи поведінку об'єднання.
Програмне забезпечення може покладатися на 32-розрядні бібліотеки. Загалом, 64-бітна програма працюватиме лише з 64-бітовими бібліотеками через припущення про стек, покажчики тощо.

Складність, про яку ви ставите у своєму запитанні, полягає лише в тому, що в деяких кодових базах може бути мільйони рядків коду, які виконують небезпечні операції, роблять небезпечні припущення, мають ярлики та розумні "оптимізації", що вводяться розробниками. Код або не буде компілюватися в 64-бітовому середовищі, або буде компілюватися, але має помилки show-stopper. Щоб виправити всі проблеми, може знадобитися багато часу. Можливо, компанія виправить їх з часом, поки не вийде 64-бітна версія. Можливо, компанія розробить "версію 2" поряд з поточними версіями технічного обслуговування, оскільки необхідна загальна перезапис.

Мораль історії полягає в тому, щоб писати чистий код і не намагатися вдруге відгадати компілятор або додати розумні оптимізації, які не потрібні, можуть зламати програмне забезпечення і, мабуть, не допомогти все одно.

Ця стаття описується набагато детальніше, ніж я міг би сподіватися, щоб включити у цю відповідь: 20 питань перенесення коду C ++ на 64-бітну платформу

— Тулан Кордова
джерело

Питання можуть піти і далі, ніж просто компіляція; У мене є друг-музикант, який не може використовувати доступну 64-бітну FL Studio, тому що їм потрібно багато VSTi, які є лише 32-бітовими; інші архітектури плагінів, засновані на динамічних посиланнях, піддаються впливу.

— StarWeaver

Дякую за редагування: Я зазвичай ДУЖЕ вибагливий до граматики, але допустив кілька помилок. І @StarWeaver я думаю, що я торкнувся цього, коли сказав, що код може компілюватись, але у ньому є помилки. Це все ще повертається до моєї точки зору написання чистого коду для будь-якої мови та платформи, на яку ви орієнтовані.

"мають помилки на стоп-шоу" Показати, що пробка очевидна і "на вашому обличчі", і з нею можна боротися. Я вважаю, що це, мабуть, гірше, - це всі проблеми, які призводять до невірних неправильних результатів, які довго залишаться непоміченими.

— Бурхан Алі