Почему может быть сложно создать 64-битную версию программы?

В моем недолгом программировании было легко скомпилировать любой из моих C ++, Java и т. Д. Для 32- или 64-битной машины, если у меня есть полный исходный код программы.

Но много программного обеспечения не выпущено 64-битных. Самое досадное, что пока нет 64-битной версии движка Unity.

Что мешает компилировать некоторые программы для 64-битных машин?

compiler 64-bit 32-bit

— calben
источник

потому что глупые программисты продолжают предполагатьsizeof(int)==sizeof(void*)

— чокнутый урод

Главной причиной в нашей среде является зависимость от некоторых сторонних компонентов, которые не доступны как 64-битные. Не знаю, относится ли это и к Unity, но я бы не удивился, если бы это было так.

— Док Браун

Они могут использовать 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 должно быть первым пунктом в этом списке, а не просто примечанием.

— Док Браун

Не могли бы вы подробнее остановиться на проблеме размера указателя int? Это потому, что в 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-битной программе. Это не работает.
Операции сдвига битов могут давать разные результаты, если используемый целочисленный тип имеет другой размер. Это может быть проблемой при использовании обычного типа данных вместо стандартного определения типа, такого какint32_t
Тип данных, используемый в объединении, может изменять размеры, изменяя поведение объединения.
Программное обеспечение может полагаться только на 32-битные библиотеки. В целом, 64-битная программа будет работать только с 64-битными библиотеками из-за предположений о стеке, указателях и т. Д.

Трудность, о которой вы спрашиваете в своем вопросе, заключается в том, что в некоторых основах кода могут быть миллионы строк кода, которые выполняют небезопасные операции, делают небезопасные предположения, имеют ярлыки и умные «оптимизации», вводимые разработчиками. Код либо не скомпилируется в 64-битной среде, либо скомпилируется, но содержит ошибки show-stopper. Чтобы решить все проблемы, может потребоваться много времени. Возможно, компания исправит их со временем, пока не появится возможность выпустить 64-битную версию. Возможно, компания разработает «версию 2» наряду с текущими выпусками обслуживания, потому что необходимо полное переписывание.

Мораль этой истории состоит в том, чтобы писать чистый код и не пытаться угадать компилятор или добавлять умные оптимизации, которые не нужны, могут сломать программное обеспечение и, вероятно, в любом случае не помогут.

Эта статья раскрывает гораздо больше деталей, чем я мог бы включить в этот ответ: 20 вопросов о переносе кода C ++ на 64-битную платформу

— Тулаинс Кордова
источник

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

— StarWeaver

Спасибо за редактирование: я обычно очень придирчив к грамматике, но допустил несколько ошибок. И @StarWeaver, я думаю, я затронул это, когда сказал, что код может компилироваться, но есть ошибки. Это все еще восходит к моей мысли о написании чистого кода для любого языка и платформы, на которую вы ориентируетесь.

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

— Бурхан Али