В моем недолгом программировании было легко скомпилировать любой из моих C ++, Java и т. Д. Для 32- или 64-битной машины, если у меня есть полный исходный код программы.
Но много программного обеспечения не выпущено 64-битных. Самое досадное, что пока нет 64-битной версии движка Unity.
Что мешает компилировать некоторые программы для 64-битных машин?
sizeof(int)==sizeof(void*)operator*дляint, но указатели не нуждаются в этом. Кроме того, большинство сред Linux и Unix также имеютint32-битную скорость.Ответы:
Общая проблема заключается в том, что в программе очень легко кодировать недокументированные предположения, и очень трудно найти места, где эти предположения были сделаны. Языки высокого уровня, как правило, в некоторой степени изолируют нас от этих проблем, но в языках более низкого уровня, используемых для реализации платформ и сервисов, легко делать вещи, которые не обязательно переносимы между архитектурами:
Предполагая, что
intэто достаточно большой, чтобы хранить указательПредполагая свойства представления указателей, например, для маркировки указателей
Предполагая, что указатели данных и указатели кода имеют одинаковый размер
Существует также практическая проблема управления релизами. Если я сделаю только сборку x86, она все равно будет работать на x86-64, хотя, возможно, медленнее из-за ограниченной доступности регистров. Принимая во внимание, что если я собираю для x86 и x86-64, я должен теперь протестировать обе архитектуры и устранить ошибки, которые могут возникнуть только в одной архитектуре, увеличивая стоимость доставки нового выпуска.
источник
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-битную платформу
источник