Хитрости ARM-процессоров iOS-устройств

Сегодня мы представляем вашему вниманию пересказ статьи Пьера Лебопена (Pierre Lebeaupin) «Некоторые вещи, которые разработчикам под iOS следовало бы знать об архитектуре ARM» («A few things iOS developers ought to know about the ARM architecture») от 19 июля 2010 года (с дополнениями от 25 сентября 2011 года), опубликованной ресурсом Wandering Coder. Надеемся, что этот материал будет интересен и полезен не только разработчикам, но и всем тем, кто интересуется проблемами разработки приложений для мобильной операционной системы iOS и внутренним устройством популярных планшетов и смартфонов компании Apple.

XCode

Когда я работал над своей статьей «Introduction to NEON on iPhone», я полагал, что читатели обладают некоторой суммой знаний о процессорах iOS-устройств. В ходе сетевых дискуссий я понял, что часть этой информации, к сожалению, многим неизвестна. Кроме того, я полагаю, что эта информация будет полезным подспорьем для программирования под iPhone (не только в том случае, если вас интересует NEON), даже если вы программируете на языке высокого уровня Objective-C. Вы можете обойтись и без этих знаний, но обладание ими усовершенствует вашу квалификацию разработчика программ для iPhone.

Вводная информация

Все недавно представленные iOS-устройства базируются на процессорах с ARM-архитектурой. Как вы сможете убедиться в ходе прочтения данного материала, эта архитектура несколько отличается от того, к чему вы привыкли на платформах для настольных систем, к которым относятся и x86 и PowerPC. Конечно же, ARM-архитектуру нельзя назвать ни узкоспециализированной, ни нишевой. Почти все мобильные телефоны (и не только смартфоны) базируются на процессорах этого типа, практически все iPod базируются на них же, как и почти все MP3-плееры. Процессоры этой же архитектуры находятся внутри большинства КПК и Pocket PC. Приставки Nintendo тоже базируются на ARM со времен GBA. Сейчас даже некоторые модели калькуляторов от TI и HP базируются на ARM-процессорах. Если говорить о прошлом, то нужно напомнить, что и Newton обладал ARM-процессором (известно, что Apple давний инвестор ARM). И это только известные устройства, не считая огромного множества ARM-процессоров, играющих вспомогательные роли.

ARM-процессоры прославились своими малыми размерами, низким энергопотреблением и высокой производительностью (в рамках своей категории, разумеется). Эти процессоры характеризуются прямым порядком передачи байтов, как и x86. Существуют также процессоры RISC-архитектуры, к которым относятся MIPS, PowerPC и другие. Следует отметить, что симулятор не выполняет код, созданный для ARM. Для запуска на симуляторе приложение компилируется под архитектуру x86 и выполняется как родное для этой архитектуры. Поэтому приложение следует тестировать на том типе устройства, для которого оно предназначено.

Разновидности ARM-архитектуры (ARMv7, ARM11, Cortex A8 и A4)

Существует несколько версий ARM-архитектуры, разработанных в разное время. В каждой из них добавлено несколько новых инструкций, а также внесены иные усовершенствования. Это затрудняет обратную совместимость. В первом iPhone применялся процессор ARMv6 (сокращенно от «ARM шестой версии»), в более новых моделях телефона применяется ARMv7 (ARM седьмой версии). Осуществляя компиляцию кода, вам следует уточнять версию архитектуры, для которой предназначено приложение, чтобы компилятор мог ограничиться только поддерживаемым данной версией набором инструкций. Это же касается и ассемблера, который будет отмечать те инструкции кода, которые поддерживаются данной версией архитектуры. Итогом становится конечная программа, ориентированная на конкретную версию архитектуры: ARMv6 или ARMv7 (или ARMv5 или ARMv4, но принимайте во внимание то, что ARMv6 является базовой при разработке приложений под iOS, весьма маловероятно, что вы это осознавали). Объектные и исполняемые файлы маркируются для соответствующей архитектуры запуском otool -vh foo.o на одном из ваших объектных или исполняемых файлов.

Дополнение от 25 сентября 2011 года:

Не перепутайте ARMv6 и ARMv7 с ARM6 и ARM7. Два последних являются старыми моделями процессоров (или скорее семействами моделей). В свою очередь ARMv6 и ARMv7 являются версиями архитектуры ARM.

Было бы неправильным сказать, что iPhone обладает «процессором ARMv6», подразумевая, что ARMv6 это название процессора, поскольку ARMv6 является не моделью процессора, а набором выполняемых процессором инструкций, а это ничего не говорит о конкретной реализации процессора. Конкретная модель применяемого в iPhone называется ARM11 (если быть более точным, то ARM1176JZF-S, но так говорят крайне редко, просто запомните, что он относится к семейству ARM11).

Как говорилось ранее, этот процессор способен выполнять набор инструкций ARMv6. Процессоры ARM11 применялись в iPhone до выхода iPhone 3GS, который базируется на ядре процессора Cortex A8, который стал использоваться с тех пор во всех iOS-устройствах. Cortex A8 способен выполнять набор инструкций ARMv7, если выражаться проще, то можно сказать, что он поддерживает ARMv7.

Дополнение от 25 сентября 2011 года:

Применяемый в iPad 2 (и, вероятно, в более поздних устройствах) процессор поддерживает тот же набор инструкций ARMv7, но уже не является Cortex A8. Технические подробности пока неизвестны, и я не видел ни одного подтверждения тому, но я уверен, что iPad 2 базируется на двух ядрах Cortex A9.

Вынужден посоветовать не ходить по кругу и не писать кода, позволяющего определить на каком устройстве код выполняется и не пытаться вычислить, какую архитектуру он поддерживает, базируясь на информации об уже выпущенных устройствах. Кроме того, что это самый бесполезный код, который вы только можете написать, он может вызвать сбой при запуске на устройстве, выпущенном после вашего приложения. Так что, пожалуйста, не делайте этого. На самом деле у вас есть информация о том, что устройства поддерживают набор инструкций ARMv7, а некоторые относительно старые ARMv6.

В ответ вы можете воскликнуть: «Я думал, что в iPad и iPhone 4 используется процессор A4, а не Cortex A8?!» На самом деле название A4 относится ко всей системе чипа, куда входит не только ядро Cortex A8, а также графическое аппаратное обеспечение, акселераторы видео- и аудиокодеков и иные цифровые блоки. Однокристальный процессор и ядро процессора это совсем разные вещи. Ядро процессора не занимает даже большей части пространства кремниевого кристалла.

Набор инструкций ARMv7 в новых устройствах будет совершенно бесполезен, если не использовать его преимущества. Вы можете использовать эти преимущества, но таким образом вы делаете свои приложения несовместимыми с более ранними устройствами, хотя, вероятно, не хотели таких последствий. Вы не знаете как выйти из этого тупика? Выход находится на поверхности. Компилируйте свой код дважды, для ARMv6 и для ARMv7. Соединяйте исполняемые модули в двоичный код в таблице распределения файлов, а устройство само выберет тот из файлов, который лучше им поддерживается.

Разумеется, таблица распределения файлов не подходит для группировки кода, ориентированного на совершенно различные архитектуры (например, PowerPC и Intel) или 32- и 64-битные версии одной и той же архитектуры, а только для двух вариантов одной архитектуры (в терминологии Mach-O «двух подтипов процессора»). С точки зрения программиста все решения принимаются во время компиляции: ориентированный на ARMv6 код неизменно будет запускаться на ARMv6-устройствах, а код под ARMv7 — только на ARMv7-устройствах (или устройствах с еще более расширенным набором команд).

Если вы читали мою статью о NEON, то, возможно, помните мои советы о том, как реализовать определение и выбор во время запуска. Если вы сейчас обратитесь к этой статье, то обнаружите, что я удалил эту часть и больше не рекомендую использовать этот метод. Сделано это было по той причине, что будет невозможно (или, как минимум, очень сложно и чревато ошибками) обеспечить работоспособность такого кода на грядущих процессорах с набором инструкций ARMv8. Вам следует принимать решение на стадии компиляции и воспользоваться таблицей распределения файлов, если вы хотите, чтобы ваше приложение запускалось на устройствах с набором инструкций ARMv6 и при этом ARMv7-устройствах могло использовать преимущества нового набора команд.

Дополнение от 25 сентября 2011 года:

Причина, по которой я не стал пояснять, почему вам следует хотеть использовать преимущества ARMv7, проста. Я посвятил этой теме новую статью.

По этому вопросу хотелось бы сделать еще одно пояснение. ARM-архетиктура процессоров для iOS-устройств не в полной мере соответствует понятию об ARM-процессорах в целом. Здесь следует привести пример. Набор команд ARMv6 для iOS предполагает поддержку инструкций для работы с плавающей точкой (если быть точным, речь идет о наборе VFPv2). Этот набор инструкций является необязательной частью набора ARMv6, тем не менее в iOS-устройствах присутствует с тех самых пор, когда был представлен первый iPhone. Таким образом, наличие поддержки инструкций для работы с плавающей точкой на аппаратном уровне при работе над приложениями для iOS-устройств предполагается по умолчанию.

Другим примером являются ARMv7 и NEON. NEON это необязательная часть профиля ARMv7-A, тем не менее NEON присутствует во всех iOS-устройствах, поддерживающих набор инструкций ARMv7. Следовательно, работая над приложениями для iOS, следует исходить из того, что NEON поддерживается (при условии поддержки процессором устройства набора инструкций ARMv7).

Настала пора кратко прорезюмировать вышесказанное:
1. Первые iOS-устройства базировались на процессорах ARM11, поддерживающих набор инструкций ARMv6.
2. Начиная с iPhone 3GS, iOS-устройства базируются на процессорах Cortex A8, поддерживающих набор инструкций ARMv7.
3. Ядро процессора (в данном случае, Cortex A8) является только частью однокристальной системы, чаще именуемой «процессором A4».
4. iPad 2 базируется не на Cortex A8, а скорее всего, на двух ядрах Cortex A9, которые поддерживают тот же набор инструкций ARMv7.

Выполнение инструкций с условием

Интересной функцией архитектуры ARM является то, что большинство инструкций могут исполняться при выполнении условия. Задается определенное условие, в случае, если оно не выполняется («false»), не исполняется и инструкция. Это позволяет более эффективно использовать короткие блоки с условным оператором «if». Традиционный метод состоит в том, что в случае невыполнения условия («false») начинает выполняться часть программы, находящаяся за блоком. Вместо этого, инструкции в блоке упорядочены таким образом, что не требуется перехода по лишним ветвям.

Но сейчас я говорю об этом не потому, что оператор «if» делает код более эффективным. Я говорю об этом, поскольку на этапе отладки возможны неожиданности. Временами вы можете увидеть, как отладчик в «if»-блоке, по условиям которого, как вам известно, выдается результат «false», например, выдает ошибку или обходит этот условный цикл «if-else». Это происходит потому, что процессор успешно проходит этот код, но некоторые его части не выполняются в реальности, поскольку их выполнение обусловлено. Кроме того, если вы поместите в блок «if» точку прерывания, она может сработать даже в том случае, если по условию возвращается результат «false».

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

Набор инструкций Thumb архитектуры ARM

Инструкции набора Thumb, входящего в общий набор инструкций архитектуры ARM, сжаты и занимают всего по 16 бит (все инструкции ARM характеризуются 32-битным размером. Thumb является 32-битной архитектурой, просто таким образом инструкции занимают меньше места). Thumb не является другой архитектурой, скорее их следует рассматривать в качестве сокращенной записи наиболее распространенных инструкций и функций все той же архитектуры ARM.

Преимущества подобного подхода к записи очевидны и состоят в том, что таким образом сокращается размер кода, экономится память и кэш, код становится менее емким. Это наиболее важно для приложений для микроконтроллеров, но не теряет своей актуальности и в iOS-устройствах. Поэтому этот набор по умолчанию включен в проектах Xcode iOS. Сокращение размера кода это, конечно, прекрасно, но вдвое его сократить все равно не получится, поскольку порой две инструкции Thumb являются эквивалентом одной инструкции ARM.

Инструкции ARM и Thumb не могут смешиваться в свободном порядке, поскольку процессору при переходе от инструкций одного типа к другому переключаться между режимами. Это может случиться только тогда, когда происходит обращение к функции или возврат результата из нее. В данном случае функция в целом может быть как Thumb, так и ARM. На практике вы не можете управлять процессом компиляции того или иного кода в инструкции Thumb или ARM на уровне функции, только на уровне исходного файла.

Если приложение компилируется для набора инструкций ARMv6, компиляция в виде Thumb является очень компромиссным решением. Код Thumb для ARMv6 имеет доступ к немногим регистрам, не может работать с условными инструкциями и, в частности, не может работать с плавающей точкой на аппаратном уровне. Код Thumb с плавающей точкой вызывает соответствующую системную инструкцию для обработки. Да, вот так медленно. По этой причине я бы рекомендовал отключать режим Thumb в случаях, когда код ориентирован на набор функций ARMv6. Если же вы хотите оставить его включенным, проверьте ваш код и, если некоторые его части работают медленно, прежде всего следует отключить Thumb по крайней мере для этих фрагментов (это просто сделать с помощью специального указателя для компилятора Xcode, используйте -mno-thumb). Помните, что вычисления с плавающей точкой довольно часто встречаются при разработке для платформы iOS с тех пор, как в Quartz и Core Animation используется система координат с плавающей точкой.

Если код компилируется для ARMv7, эти препятствия, конечно же, устраняются, поскольку набор инструкций ARMv7 содержит Thumb-2, расширение набора инструкций Thumb, добавляющее поддержку обусловленных инструкций и 32-битных инструкций Thumb. Таким образом обеспечивается доступ ко всем регистрам ARM, а также поддержка плавающей точки и NEON. Для набора инструкций ARMv7 Thumb обеспечивает сокращение размера кода, поэтому его следует оставить включенным (или включить заново, если вы уже успели отключить его). Используйте набор условных настроек Xcode таким образом, чтобы Thumb был включен для ARMv7, но отключен для ARMv6.

Дополнение от 25 сентября 2011 года:

Чтобы добавить набор условных настроек для Xcode 3, следуйте инструкциям Джеффа Ламарша (Jeff Lamarche), данным им в последнем абзаце его заметки «Thumb» от 9 июля 2010 года, опубликованной в блоге iPhone Development. Для Xcode 4 необходимо следовать инструкциям компании Apple, принимая во внимание то, что вы можете добавить условные настройки только при выборе настроек специальной конфигурации (в ином случае пункт меню будет затемнен).

В документации по ARM и обсуждениях в Интернете вы можете встретиться с упоминанием того, что при использовании Thumb код должен проверяться на «взаимодействие». Если только вы не пишете код на ассемблере, вам не надо переживать на сей счет. Весь код на iOS-платформе «взаимодействует» («Взаимодействие» адресует к набору правил, позволяющих скомпилированным в виде ARM-инструкций функциям непосредственно обращаться к функциям, скомпилированным в виде Thumb-инструкций, соответственно обращение реализуется и в обратном порядке безо всяких проблем и настолько же прозрачно, как к этому привыкли программисты, пишущие на языке C). Shark или же инструмент Time Profile могут испытывать трудности в попытке определить, относится ли та или иная функция к ARM или Thumb. Если вы видите неработоспособную или бессмысленную инструкцию, следует попробовать переключиться между ARM и Thumb.

Выравнивание доступов

Платформа iOS поддерживает невыровненные доступы к памяти. Они, конечно же, осуществляются медленнее выровненных, поэтому старайтесь их избегать. В некоторых отдельных случаях (куда входят загрузка и сохранения множественных инструкций, если вам это интересно) невыровненные доступы могут работать в сотни раз медленнее выровненных. Это происходит потому, что процессор не может с ними справиться и обращается за помощью к операционной системе. В статье Джонатана Ренча «Data alignment: Straighten up and fly right», опубликованной сайтом компании IBM, описывается подобный феномен, наблюдавшийся на платформе PowerPC, на которой невыровненные доступы осуществлялись вдвое медленнее выровненных. Поэтому, будьте внимательнее, выравнивание данных все еще актуально.

Действие деления в iOS-устройствах осуществляется только на уровне операционной системы

Эта тема не перестает удивлять каждого. Откройте инструкцию к архитектуре ARM. Если у вас ее до сих пор нет, то посмотрите в разделе «Architecture Overview» статьи «Introduction to NEON on iPhone» и найдите инструкцию целочисленного деления. Только не удивляйтесь, но архитектура ARM не поддерживает целочисленное деление на аппаратном уровне. Эта проблема решается на уровне программного обеспечения. Если вы скомпилируете следующий код:

int ThousandDividedBy(int divisor)
{
return 1000/divisor;
}

в код ассемблера, то увидите, что компилятор добавит обращение к функции под названием «___divsi3». Эта системная функция осуществляет действие деления на программном уровне (отметим, что делитель не является постоянным, в ином случае, по всей вероятности деление осуществляется через умножение). Это означает, что в iOS деление осуществляется на уровне операционной системы.

Однако, прочтя наконец инструкцию к архитектуре ARM, вы можете воскликнуть: «Вы же неправы! ARM-инструкция деления существует, их даже две! Смотрите сюда, вот они, sdiv и udiv!». Вынужден вас огорчить, эти инструкции имеются только в профилях ARMv7-R и ARMv7-M (для процессоров реального времени и встроенных систем, то есть для микроконтроллеров двигателей и наручных часов). В наборе инструкций ARMv7-A, на котором базируются iOS-устройства, инструкции деления отсутствуют.

GCC

Не секрет, что ARM-код, созданный посредством GCC, никуда не годится. Для создания приложений под другие платформы на базе ARM, профессиональные разработчики используют RVDS, инструментарий, предоставляемый непосредственно ARM, но на платформе iOS это невозможно, поскольку RVDS не поддерживает загрузку файлов формата Mach-O, используемых в системах OS X. RVDS поддерживает только загрузку ELF. Пока что я не посвящал много времени тестированию всего этого. Мне, по крайней мере, довелось увидеть обнадеживающие усовершенствования в 64-битном целочисленном коде (а это особо выделяющееся слабое место GCC on ARM) при использовании LLVM. Будем надеяться, что LLVM проявит свое превосходство над GCC во всех отношениях.

Источник: Wanderingcoder.net (Пьер Лебопен), Iphonedevelopment.blogspot.com (Джеф Ламарш), Ibm.com (Джонатан Ренч), Favo.asia