64-разрядная инициатива

Начиная с версии 10.4 (Тигр) OS X перемещался в модель, поддерживающую 64-разрядное адресное пространство. В этой модели, названной LP64, long целые числа и указатели - оба 8 байтов (64 бита) вместо 4 байтов. Кроме того, size_t целый тип составляет 8 байтов вместо 4 байтов. Выравнивание этих типов для LP64 также увеличилось до 8 байтов. Размеры всех других примитивных целых типов (char, int, off_t, и т.д.), остаются, как они находятся в 32-разрядной модели (ILP32), но выравнивании некоторых — а именно, long long и pos_t— увеличился до 8 байтов для LP64.

На архитектурах Intel 64-разрядный режим также влечет за собой увеличение и в числе регистров и в их ширине, а также изменении в соглашениях о вызовах передать параметры в регистрах вместо на штабеле. Как прямое следствие этих изменений, 64-разрядные исполнимые программы в основанных на Intel системах OS X могут видеть повышение производительности. (Расширение регистров не происходит на архитектуре PowerPC, потому что это было разработано для 64-разрядных вычислений с самого начала.) Несмотря на то, что ядро (Дарвин) остается 32-разрядным, оно поддерживает 64-разрядное программное обеспечение в пространстве пользователя.

Все указатели в 64-разрядном процессе составляют 64 бита; нет никакого «смешанного режима», в котором некоторые указатели составляют 32 бита, и другие - 64 бита. Следовательно, все двоичные файлы поддержки должны были выполнить процесс, включая платформы, библиотеки и плагины, должны быть 64-разрядные способный, если процесс должен работать в 64-разрядном адресном пространстве. Все зависимости требуют портирования на 64-разрядный.

Как часть 64-разрядной инициативы для OS X v10.5 (Leopard), Apple портирует все системные платформы, библиотеки и плагины для поддержки 64-разрядного обращения. Они упаковываются для поддержки и 32-разрядных и 64-разрядных исполнимых программ. Таким образом, если у Вас есть 32-разрядное приложение и 64-разрядное приложение, работающее одновременно, оба штабеля платформы, от которых приложения имеют зависимости, загружаются в память. Компилятор GCC, компоновщик, отладчик и другие средства разработки были также изменены для поддержки 64-разрядного обращения. Системные демоны также изменяются для поддержки 64-разрядных процессов. Платформы Какао, а также время выполнения Objective C и связанные средства разработки являются частью усилия по портированию. (Изменения Какао описаны в 64-разрядных Изменениях В Какао API.)

Несколько изменений были также внесены для посредничания целых типов на нижних уровнях системы. Например, базовый тип примитива для CFIndex в Базовой Основе был изменен, чтобы быть 64-разрядным в то время как это для SInt32 в Углероде Ядро было изменено, чтобы остаться 32-разрядным в 64-разрядном мире. Эти изменения проникают на более высокие уровни системы, влияя на платформы, где они представляют эти типы в своем APIs.

Существует несколько последствий и импликаций перехода к 64-разрядному адресному пространству:

• 64-разрядная исполнимая программа может одновременно получить доступ к 16 эксабайтам виртуального адресного пространства.

• Требования системной памяти более чем удвоятся, и из-за больших структур данных и из-за потребности в двух штабелях платформы, загруженных одновременно.

Важная доля 64-разрядной инициативы должна поддержать совместимость на уровне двоичных кодов для существующих 32-разрядных приложений, как только 64-разрядные изменения внесены в системные платформы, библиотеки и плагины. Иногда это означает сохранять базовый тип примитива тем же для 32-разрядных значений.

Я должен переместить свой проект в 64-разрядный?

Для OS X v10.5 (Leopard), просто небольшой процент проектов имеет любую потребность переместиться в 64-разрядное адресное пространство. Обычно эти проекты для приложений, требующих увеличенного адресного пространства для управления большими наборами данных, или которые должны иметь произвольный доступ к объектам данных чрезмерные 4 ГБ. Некоторые примеры приложений, попадающих в эту категорию, включают тех, которые выполняют научные вычисления, крупномасштабный 3D рендеринг и анимацию, анализ данных и специализированную обработку изображений.

Для выпусков после OS X v10.5 ожидается, что все больше проектов программного обеспечения — включая большинство пользовательских приложений — сделает переход к 64-разрядному. Существует несколько причин этого ожидания:

• Конкурирующие платформы. Microsoft Windows XP уже имеет 64-разрядную версию, и Windows Vista также будет 64-разрядный способный.

• Аппаратное развитие. Поскольку тенденция к понижению в цене аппаратных компонентов (таких как микросхемы памяти) продолжается, типичная конфигурация компьютеров будет расти, чтобы позволить 64-разрядным вычислениям становиться нормой. Кроме того, как отмечено выше, можно видеть повышения производительности для 64 исполнимых программ, работающих на основанных на Intel компьютерах Macintosh.

• Пользовательское требование. Вместе с аппаратными конфигурациями будут также расти пользовательские ожидания. В 64-разрядной способной системе OS X с, скажем, 32 ГБ памяти немного пользователей будут довольны приложением, которое может получить доступ не больше, чем к 4 ГБ данных.

Таким образом несмотря на то, что Ваше приложение, возможно, сразу не должно делать переход к 64-разрядному, через несколько лет это будет. Можно начать теперь подготавливать проекты к этому переходу, продолжившись шаг за шагом. Во-первых, сделайте свои проекты 64-разрядными чистый путем слияния новых 64-разрядных типов в код и использования условных выражений препроцессора для поддержания исходной совместимости. Проект должен быть в состоянии скомпилировать без ошибок и работать. Затем сделайте свои проекты 64-разрядными, включил при помощи APIs тому экспрессу 64-разрядные количества. Наконец, сделайте свои проекты 64-разрядными способный путем обеспечения, что все пути выполнения кода способны к контакту с 64-разрядными количествами.

Можно упростить процесс перехода путем принятия собственных OS X технологий и типов данных. Например, при использовании Базовых Данных (см. Базовое Руководство по программированию Данных) для управления данными приложения, можно сократить количество параметров, которые необходимо рассмотреть в принятии. Типы атрибута, которые Вы указываете для Базовых объектов Данных, являются тем же на 32-и 64-разрядные платформы. Формат файла независим от платформы (это - то же, является ли узлом Intel - или основанный на PowerPC, 32-или 64-разрядный); кроме того, с помощью ленивой инициализации данных, доступной с хранилищем SQLite, Базовые Данные позволяют Вам работать с наборами данных, размер которых ограничивается прежде всего узлом. Вместе эти функции упрощают для Вас масштабироваться беспрепятственно от 32-до 64-разрядного.

Можно использовать существующие технологии для подавания заявки, «универсальной» упаковочными двоичными файлами в комплекте приложений с 64-разрядными и 32-разрядными вариантами, объединенными с вариантами для PowerPC и архитектур Intel. Таким образом Ваше приложение могло иметь двоичные файлы мультиархитектуры с четырьмя путями, с двоичными файлами для 32-разрядного PowerPC, 64-разрядный PowerPC, 32-разрядный Intel, и 64-разрядный Intel. Обычно Вы захотите приложение, поставляющее столь же 64-разрядный для поставки как 32-разрядный также, так как Вы хотите, чтобы оно работало на только аппаратных средствах на 32 бита, которые много лет будут распространены.