Как работает 64-битный код на OS-X 10.5?
Сначала я думал, что 64-разрядные инструкции не будут работать на OS-X 10.5.
Я написал небольшую тестовую программу и скомпилировал ее с GCC -m64, я использовал long long для моих 64-битных целых чисел.
Используемые инструкции по сборке выглядят как 64-битные. например. imultq а также movq 8(%rbp),%rax,
Кажется, я работаю.
Я только использую printf для отображения 64-битных значений с помощью %lld,
- Это ожидаемое поведение?
- Есть ли
gotcha'sчто может привести к сбою? - Могу ли я задать несколько вопросов в вопросе?
- Это работает на других ОС?
3 ответа
Просто чтобы прояснить это, вот ситуация для 32- и 64-битных исполняемых файлов в OS X:
И 32-, и 64-битные исполняемые файлы пользовательского пространства могут быть запущены как на 32-, так и на 64-битных ядрах в OS X 10.6 без эмуляции. На 10.4 и 10.5 32-разрядные и 64-разрядные исполняемые файлы могут работать в 32-разрядном ядре. (Это не так в Windows)
Системные библиотеки и фреймворки пользовательского пространства построены на 32/64-битной версии 10.5 и 10.6. Вы можете ссылаться на них как обычно, независимо от того, используете ли вы 32-битную, 64-битную или обе версии. Несколько библиотек (в основном слой POSIX) также построены с 32/64-битной версией 10.4, но многие из них - нет.
На 10.6 инструменты сборки создают 64-битные исполняемые файлы по умолчанию. На 10.5 и более ранних версиях по умолчанию используется 32-разрядная версия.
На 10.6 исполняемые файлы, которые построены жирными, по умолчанию будут работать на 64-битной стороне. На 10.5 и более ранних 32-битная сторона выполняется по умолчанию.
Вы всегда можете вручную указать, какой фрагмент толстого исполняемого файла использовать, используя
archкоманда. например.arch -arch i386 someCommandToRunThatIWantToRunIn32BitMode, Для пакетов приложений вы можете либо запустить их из командной строки, либо есть предпочтение, если вы "получаете информацию" о приложении.OS X и Linux используют модель LP64 для 64-битных исполняемых файлов. Указатели и
longимеют ширину 64 бита,intпо-прежнему 32 бита, иlong longвсе еще 64 бит. (Windows использует модель LLP64 вместо -long32-битная ширина в 64-битной Windows).
Mac OS X 10.5 довольно хорошо поддерживает 64-битные пользовательские приложения. Фактически, Xcode работает в 64-битной версии 10.5 на совместимой архитектуре.
Это только встроенные приложения (Finder, Safari, фреймворки, демоны и т. Д.) Также имеют 64-битную версию в 10.6.
Мета: Мне не нравится, когда ответы удаляются. Я думаю, это где-то обсуждалось.
Как бы то ни было, KennyTM и другие добрые единоличники дали мне старт, и хотя один ответ был удален, я высоко оценил ваши усилия.
Похоже, что это ожидаемое поведение на Mac, и даже кажется, что он работает на 32-битном Linux (хотя я не тестировал подробно)
Ага. GCC ведет себя по-разному (по крайней мере, в моем ограниченном наблюдении) для 32 (-m32) и 64 (-m64) битовых режимов. В 32-битном я смог получить доступ к переменным аргументам, используя массив. В 64-битном режиме это просто не работает.
Я узнал, что вы ДОЛЖНЫ получить доступ к переменным параметрам, используя va_list, как определено в stdarg.h, потому что он работает в обоих режимах.
Теперь у меня есть программа командной строки, которая запускает и проходит все мои тесты в 32-битном и 64-битном режимах на Mac OS-X.
Программа реализует сборщик мусора из связанного списка, вытягивающий 16-байтовые выровненные объекты, выделенные malloc, из глобального списка, а также из машинных регистров и стека - на самом деле, есть дополнительные регистры в 64-битном режиме, поэтому у меня еще есть немного работы, чтобы делать.
Объекты представляют собой набор из 32- или 64-битных слов, которые соединяются вместе, образуя структуры данных, подобные LISP/Scheme.
Таким образом, это сложная программа, которая много работает с указателями и работает одинаково в 32- и 64-битных режимах.
Задание нескольких вопросов не дает вам все ответы, которые вы могли бы хотеть.
Кажется, что работает, как я написал, на Linux.
Еще раз спасибо за помощь в этом.