Что значит отказ от поддержки 32-битной архитектуры в будущих процессорах ARM
Константин Иванов
Во время выступления на конференции Arm DevSummit Пол Вильямсон, вице-президент и глава клиентского подразделения ARM, заявил, что новые процессоры Arm Cortex-A, то есть те самые, что служат основой платформы для чипсета вашего смартфона, к 2022 году будут поддерживать только 64-битную архитектуру. Это означает, что на аппаратном уровне поддержки 32-битных приложений в будущем не будет, а следовательно, это небольшой, но весьма значимый шаг для будущего смартфонов и ОС Android.
Если вы волновались насчет поддержки приложений, то напрасно. Компания Google с августа 2019 года требует, чтобы все приложения в магазине Google Play были 64-битными. Со стороны ARM также подчеркивают, что около 60% приложений уже совместимы с 64-битной архитектурой. Большая часть тех, что 64-бита не поддерживают, находятся за пределами западных экосистем, созданных Apple и Google. Так что большинство приложений или уже 64-битные, или у их создателей есть еще масса времени для обеспечения такой поддержки. Худший вариант – это старые приложения, у которых уже нет поддержки. Они просто перестанут работать.
А разве Android еще не 64-битный?
Технически ОС Android уже 64-битная. Поддержка 64-битных приложений была внедрена еще в 2014 году с обновлением до версии 5.0 Lollipop, но ОС Android и ядра ARM сохраняют поддержку 32-битных приложений. Так что называть ОС Android полностью 64-битной системой будет неверно. Это наследство в виде поддержки старой архитектуры просуществует до 2022 года с точки зрения аппаратной части, так что нет предпосылок к тому, чтобы из Android его исключили заранее. Так что для пользователей переход должен быть бесшовным.
Польза от перехода полностью на 64-битную архитектуру должна включать улучшение производительности для приложений, игр и операционной системы. В некоторых случаях оно может достигать 20%. Разработчикам больше не потребуется заботиться о поддержке двух архитектур, и они смогут сосредоточиться исключительно на 64-битной. Возможно, это даст некоторое ускорение в выпуске обновлений.
В большинстве случаев переход к 64-битной архитектуре будет заурядным событием. Смартфоны и приложения находятся в переходном периоде уже несколько лет. Так что и с точки зрения аппаратной и программной части переход давно пора завершить. В конце концов, в Apple еще в 2017 году уже сделали iOS 11 полностью 64-битной.
Что известно о 64-битных процессорах ARM
Важной новостью от Arm является то, что они наконец-то смогут избавиться от лишней части своих процессоров, которая требуется исключительно для поддержки 32-битной архитектуры. Это сэкономит полезную площадь при печати, что означает меньший физический размер ядра и его меньшую теплоотдачу, ну или большую производительность при тех же размерах.
Кодовые названия ядер Arm для 2021 и 2022 года – Matterhorn и Makalu. И вот у второго уже не будет поддержки 32 бит. Компания Arm обещает 30% прирост в производительности между ядрами 2020 года Cortex-A78 и Makalu, так что не заметить улучшение будет сложно. Переход к полностью 64-битной архитектуре начнется с больших ядер Cortex-A. При этом сам переход не будет непременно сопровождаться новой архитектурой самого ядра, такой как ArmV9. Другими словами, скорее всего, мы увидим дизайн кластера ядер, в котором будут присутствовать как полностью 64-битные Makalu, так и меньшие ядра с поддержкой 32/64-бит, такие как Cortex-A55. Хотя финальный продукт с точки зрения пользователя и разработчика будет исключительно 64-битным.
Так что до того, как появятся чипсеты, работающие исключительно с 64-битами, нам придется подождать, чтобы появились малые ядра в полностью 64-битном исполнении. Это оставляет пространство для менее производительных устройств, которые используют только меньшие ядра. Они смогут обеспечивать поддержку 32-битной архитектуры несколько дольше. И есть даже предпосылки к тому, что обновление данного типа ядер произойдет до этого момента. Это будет более новая модель в сравнении с Cortex-A55, но у нее все еще будет поддержка и 32, и 64-бит, так что тут переход будет еще более плавным.
Переход полностью на 64-бита – это важный шаг для ОС Android и компании Arm. Его значение – в упрощении в сравнении с современным состоянием, когда требуется поддержка наследия 32-битной эры. Однако не нужно воспринимать его как фундаментальное изменение экосистемы или радикальное обновление пользовательского опыта, поскольку вся сложность перехода ложится исключительно на плечи разработчиков. А простые пользователи устройств, скорее всего, вообще ничего не заметят.
ARM-ы для самых маленьких
Пару дней назад я опубликовал и потом внезапно убрал в черновики статью о плане написать про создание своей ОС для архитектуры ARM. Я сделал это, потому что получил много интересных отзывов как на Хабре, так и в G+.
Сегодня я попробую подойти к вопросу с другой стороны, я буду рассказывать о том, как программировать микроконтроллеры ARM на нарастающих по сложности примерах, пока мы не напишем свою ОС или пока мне не надоест. А может, мы перепрыгнем на ковыряние в Contiki, TinyOS, ChibiOS или FreeRTOS, кто знает, их там столько много разных и интересных (а у TinyOS еще и свой язык программирования!).
Итак, почему ARM? Возиться с 8-битными микроконтроллерами хотя и интересно, но скоро надоедает. Кроме того, средства разработки под ARM обкатаны долгим опытом и намного приятнее в работе. При этом, начать мигать светодиодами на каком-то «evaluation board» так же просто, как и на Arduino.
Небольшой экскурс в архитектуру
ARM продвигает замечательную архитектуру, которую успешно лицензирует, мне на самом деле сложно представить, в каком устройстве нет никакого присутствия продуктов этой компании. В вашем смартфоне гарантированно есть несколько ядер на базе архитектуры ARM. Еще парочка найдется в современном ноутбуке (и это даже не CPU, а так, сопутствующий контроллер какой-либо периферии), еще несколько – в автомобиле. Есть они и в других бытовых вещах: микроволновках и телевизорах.
Такая гибкость достигается тем, что в самом базовом варианте ядро ARM очень простое. Сейчас существуют три разновидности этой архитектуры. Application применяется в устройствах «общего назначения» – как основной процессор в смартфоне или нетбуке. Этот профиль самый навороченный функционально, тут есть и полноценный MMU (модуль управления памятью), возможность аппаратно выполнять инструкции Java bytecode и даже поддержка DRM-схем. Microcontroller – это полная противоположность профилю application, применяемая (внезапно!) для использования в микроконтроллерах. Тут актуально минимальное энергопотребление и детерминистическое поведение. И, наконец, real-time используется как эволюция профиля microcontroller для задач, где критично иметь гарантированное время отклика. Все эти профили получили реализацию в одном или нескольких ядрах Cortex, так, например, Cortex-A9 основан на профиле application и является частью процессора в iPhone 4S, а Cortex-M0 основан на профиле microcontroller.
Железки!
В качестве целевой платформы мы будем рассматривать работу с Cortex-M, так как она самая простая, соответственно, надо вникать в меньшее количество вопросов. В качестве тестовых устройств я предлагаю вам LPC1114 – MCU производства NXP, схему на котором можно собрать буквально на коленке (нет, правда, вам нужен только сам MCU, FTDI-кабель на 3,3 В, несколько светодиодов и резисторов). LPC1114 построен на базе Cortex-M0, так что это будет самый урезанный вариант платформы.
В качестве альтернативного варианта мы будем работать с платформой mbed, а конкретно, с моделью на базе LPC1768 (а значит, внутри там Cortex-M3, несколько более навороченный). Вариант уже не настолько бюджетный, но процесс заливки бинарников на чип и отладки упрощен максимально. Да и можно поиграться с самой платформой mbed (вкратце: это онлайн-IDE и библиотека, с помощью которой можно программить на уровне ардуины).
Приступим
Интересной особенностью современных ARM-ов является то, что их вполне реально программировать целиком на С, без применения ассемблерных вставок (хотя ассемблер не так уж и сложен, у Cortex-M0 всего 56 команд). Хотя некоторые команды в принципе не доступны из С, эту проблему решает CMSIS – Cortex Microcontroller Software Interface Standard. Это драйвер для процессора, который решает все основные задачи управления им.
Как же загружается процессор? Типична ситуация, когда он просто начинает выполнять команды с адреса 0x00000000. В нашем случае процессор несколько более умный, и рассчитывает на специально определенный формат данных в начале памяти, а именно – таблицу векторов прерываний:
Старт выполнения программы происходит следующим образом: процессор читает значение по адресу 0x00000000 и записывает его в SP (SP – регистр, который указывает на вершину стека), после чего читает значение по адресу 0x00000004 и записывает его в PC (PC – регистр, который указывает на текущую инструкцию + 4 байта). Таким образом начинает выполняться какой-то код пользователя, при этом у нас уже есть стек, указывающий куда-то в память (т.е., все условия для выполнения программы на С).
В качестве тестового упражнения мы будем мигать светодиодом. На mbed у нас их целых четыре, в схему с LPC1114 (далее — «доска») мы устанавливаем светодиод вручную.
Перед тем как непосредственно писать код, нам надо выяснить еще одну вещь, а именно – что где должно располагаться в памяти. Поскольку мы не работаем с какой-то «стандартной» ОС, то компилятор (вернее, компоновщик) не может узнать, где у него должен быть стек, где сам код, а где — куча. К счастью для нас, у семейства ядер Cortex стандартизированная карта памяти, что позволяет относительно просто портировать приложения между разными процессорами этой архитектуры. Работа с периферией, конечно, остается процессорозависимой.
Карта памяти для Cortex-M0 выглядит вот так:
У Cortex-M3 она, по сути, такая же, но несколько более детальна. Проблема тут в том, что у NXP есть свой, отдельный взгляд на этот вопрос, так что проверяем карту памяти в документации на процессор:
На самом деле, SRAM у нас начинается с 0x10000000! Вот так, одни стандарты, другие стандарты, а все равно надо тома документации листать.
Вооружившись этими знаниями, идем писать код. Для начала – таблица прерываний:
Сама таблица должна бы быть длиннее, но на самом деле мы могли бы закончить ее еще после вектора Reset, остальные у нас не сработали бы в этом примере. Но, на всякий случай, мы заполнили таблицу почти целиком (кроме пользовательских прерываний).
Теперь напишем реализацию функции main:
У mbed первый светодиод подключен к порту GPIO 1.18, на доске мы подключили светодиод к GPIO 1.8. Одни и те же пины могут выполнять разные функции, эти по умолчанию работают именно как GPIO (General Purpose I/O – линии ввода/вывода общего назначения).
Код относительно прямолинеен, если держать под рукой LPC-шный User manual (один и второй). Для начала мы указываем режим работы GPIO через регистр GPIO_DIR_REG (у наших процессоров они в разных местах, да и вообще LPC1768 может работать с GPIO более эффективно), где 1 – вывод, 0 – ввод. Потом мы запускаем бесконечный цикл, в котором пишем в порт попеременно значения 0 и 1 (0 В и 3,3 В соответственно).
Функция для «паузы» у нас работает наугад, просто прокручивая относительно долгий цикл ( volatile int не дает компилятору выоптимизировать этот цикл целиком).
Наконец, все это нужно правильно скомпоновать:
Теперь у нас есть три файла: boot.s, main.c, mem.ld, пора это все скомпилировать и, наконец, запустить. В качестве тулчейна мы будем использовать GCC, позже, возможно, я покажу как делать то же с LLVM. Пользователям OS X я советую взять тулчейн у Linaro – в самом конце списка: Bare-Metal GCC ARM Embedded. Пользователям других ОС я советую взять тулчейн там же 🙂 (разве что гентушникам будет проще сэмержить crossdev и скомпилить GCC).
Интересный момент тут — это отключение использования всех стандартных библиотек у GCC. Действительно, весь код, который попадет в итоговый бинарник – это код, который написали мы сами.
Вопрос: как компоновщик знает, куда надо засунуть таблицу прерываний? А он и не знает, там не написано :-). Он просто линкует подряд, начиная с нулевого адреса, так что порядок файлов (boot.o, потом main-c0.o) очень важен! Попробуйте слинковать наоборот или слинковать boot.o два раза и сравните вывод в lst-файле.
Хорошая идея – посмотреть на итоговый листинг (файл lst) или закинуть бинарник в дизассемблер. Даже если вы не говорите на ARM UAL, то чисто визуально можно проверить, что хотя бы таблица прерываний находится на своем месте:
Еще можно обратить внимание на забавный момент – GCC при компиляции под Cortex-M3 генерирует функцию wait() больше, чем в варианте под Cortex-M0. Правда, если включить оптимизацию то она вправит ему мозги.
Мигаем!
Все что нам осталось – залить бинарники на наши тестовые платформы. С mbed тут все максимально просто, просто скопируйте blink-c3.bin на виртуальную флешку и нажмите reset (на mbed). С доской все немного сложнее. Во-первых, для того, чтобы попасть в загрузчик, нам нужен резистор между GND и GPIO 0.1. Во-вторых, необходима программа для непосредственно прошивки. Можно использовать Flash Magic (Win, OS X), можно использовать консольную утилиту – lpc21isp:
Если у вас есть возможность запустить примеры на разных устройствах, вы заметите, что скорость мигания на них не идентична. Это связанно с тем, что у разных устройств разная частота ядра, соответственно, wait() они выполняют за разное время. В следующей части мы изучим вопросы осцилляции детальнее и сделаем четкий отсчет времени.
Как узнать архитектуру процессора вашего телефона Android
Если вы любите загружать приложения на свой телефон Android, возможно, вы столкнулись с тем, что некоторые приложения имеют разные сборки, что приводит к путанице в отношении того, какую сборку загружать и устанавливать на вашем телефоне. Эта путаница возникает из-за большого числа производителей процессоров для рынка Android. У нас есть Qualcomm, MediaTek, Samsung, Huawei и некоторые другие мелкие производители, которые разрабатывают чипсеты для рынка Android. Даже у одного и того же производителя есть разные категории чипсетов, чтобы удовлетворить потребности разных людей.
Разработчики приложений разрабатывают разные версии одного и того же приложения, чтобы они бесперебойно работали на разных устройствах с разными аппаратными конфигурациями. По этой причине разработчики из Google LLC разработали 22 варианта приложения YouTube. Таких примеров много. Если вы опытный пользователь Android, вы должны знать следующее:
Достаточно сказать, теперь следуйте этим шагам, чтобы узнать о процессоре вашего телефона.
Вы также можете попробовать следующие приложения, которые выполняют ту же функцию, что и Droid Hardware Info.
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
ARM (Advanced RISC Machine)
Многие лицензиаты разрабатывают собственные версии ядер на базе ARM: DEC StrongARM, Freescale i.MX, Intel XScale, NVIDIA Tegra, ST-Ericsson Nomadik, Krait в Qualcomm Snapdragon, Texas Instruments OMAP, Samsung Hummingbird, LG H13, Apple A6 и HiSilicon K3.
Содержание
Процессоры ARM
В настоящее время значимыми считаются несколько семейств процессоров ARM:
Популярное семейство микропроцессоров xScale фирмы Marvell (до 27 июня 2007 года — Intel) — расширение архитектуры ARM9, дополненной набором инструкций Wireless MMX, специально разработанных компанией Intel для поддержки мультимедийных приложений. Здесь можно ознакомиться с версиями ядра ARM.
Архитектура
Уже давно существует справочное руководство по архитектуре ARM, что разграничивает все типы интерфейсов, которые поддерживает ARM, так как детали реализации каждого типа процессора могут отличаться.
Архитектура развивалась с течением времени, и, начиная с ARMv7, были определены три профиля:
Профили могут поддерживать меньшее количество команд (команды определенного типа).
AArch64
AArch64 это имя для новой 64-разрядной ARM архитектуры, также известной как ARMv8 или ARM64.
AArch64 увеличил вдвое число целочисленных регистров. 32-битный ARM предоставляет 16 целочисленных регистров, из которых один — счетчик команд (англ. program counter ), еще два используются для указателя на стэк и регистра связи (англ. link register ) и 13 регистров общего назначения. В AArch64 32 целочисленных регистра, с выделенным нулевым регистром, регистром связи и регистром указателя кадра (англ. frame pointer register ). Еще один регистр зарезервирован платформой, что оставляет 28 регистров общего назначения.
AArch64 также увеличивает число регистров для чисел с плавающей запятой. Регистры в 32-битных ARM несколько странные, так что сложно сравнивать. У 32-битного ARM 32 32-битных регистров с плавающей запятой, которые могут быть представлены как 16 перекрывающихся 64-битных регистров. Кроме того, есть еще 16 независимых 64-битных регистров. AArch64 упрощает это до 32 неперекрывающихся 128-битных регистров, которые могут быть использован для данных меньшего размера. Преимущества AArch64:
Насколько это влияет на производительность зависит от конкретного кода и эффективности компилятора, который оптимизирует использование регистров. Когда архитектура Intel перешла от 32 к 64 битам, число регистров увеличилось с 8 до 16, и это было значительное изменение производительности.У ARM уже было больше регистров чем у 32-битной архитектуры Intel, так что увеличение регистров хоть и меньше повлияет на производительность, но это изменение все еще будет заметно.
AArch64 также привнес существенные изменения помимо увеличения числа регистров.
Большинство 32-битных инструкций ARM могут выполняться/не выполняться в зависимости от состояние регистра-условия. Это позволяет транслировать условные выражения (if-statements) без использования ветвления. Предполагалось, что это увеличит производительность, однако, судя по тому, что в AArch64 от этой возможности отказались, она порождала больше проблем, чем давала пользы.
В AArch64 набор SIMD (англ. single instruction, multiple data — одна инструкция, много данных) NEON полностью поддерживает стандарт IEEE754 для чисел с плавающей запятой с двойной точностью, в то время как 32-битная версия NEON поддерживала только одинарную точность и не в точности следовала стандарту для некоторых битов. В AArch64 добавили специализированные инструкции для AES шифрования и SHA-1 & SHA-256 хешей. Не слишком полезное в общем, однако существенный бонус если вы занимаетесь именно этими вопросами.
В целом, самым важным отличаем является увеличение числа регистров общего назначения и полная поддержка IEEE754-совметимой арифметики на числах с двойной точностью в NEON. Это может дать ощутимый прирост в производительности в большом числе мест.
ARMhf
ARMhf код может выполняться только на процессорах с аппаратной поддержкой вычислений с плавающей точкой. В настоящее время Debian ARMhf порт требует, по крайней мере, центральный процессор ARMv7 с Thumb-2 и VFP3D16.
Многие приложения для управления в режиме реального времени в промышленных и автомобильных полей выгоду из динамического диапазона и точности с плавающей точкой, предложенной ARM VFP. Автомобильная трансмиссия, антиблокировочная тормозная, контроль тяги, и активные системы подвески все критически важных приложений, где точность и предсказуемость являются необходимыми требованиями.
До ARMv7 архитектуры VFP стоял Вектор с плавающей точкой архитектуры, используется для векторных операций.
Там были три основные версии VFP на сегодняшний день:
Режимы
Процессор может находиться в одном из следующих операционных режимов:
Режим процессора переключается, когда возникает соответствующее исключение, или же при модификации регистра статуса.
Набор команд
Чтобы сохранить устройство чистым, простым и быстрым, оригинальное изготовление ARM было исполнено без микрокода, как и более простой 8-разрядный процессор 6502, используемый в предыдущих микрокомпьютерах от Acorn Computers. Набор команд ARM — режим, в котором исполняется 32-битный набор команд.
Набор команд Thumb
Для улучшения плотности кода процессоры, начиная с ARM7TDMI, снабжены режимом «thumb». В этом режиме процессор выполняет альтернативный набор 16-битных команд. Большинство из этих 16-разрядных команд переводятся в нормальные команды ARM. Уменьшение длины команды достигается за счёт сокрытия некоторых операндов и ограничения возможностей адресации по сравнению с режимом полного набора команд ARM.
В режиме Thumb меньшие коды операций обладают меньшей функциональностью. Например, только ветвления могут быть условными, и многие коды операций имеют ограничение в виде доступа только к половине главных регистров процессора. Более короткие коды операций в целом дают большую плотность кода, хотя некоторые операции требуют дополнительных команд. В ситуациях, когда порт памяти или ширина шины ограничены 16 битами, более короткие коды операций режима Thumb становятся гораздо производительнее по сравнению с обычным 32-битным ARM-кодом, так как меньший программный код придется загружать в процессор при ограниченной пропускной способности памяти.
Аппаратные средства типа Game Boy Advance, как правило, имеют небольшой объём оперативной памяти, доступной с полным 32-битным информационным каналом. Но большинство операций выполняется через 16-битный или более узкий информационный канал. В этом случае имеет смысл использовать Thumb-код и вручную оптимизировать некоторые тяжелые участки кода, используя переключение в режим полных 32-битных инструкций ARM.
Первым процессором с декодером Thumb-команд был ARM7TDMI. Все процессоры семейства ARM9, а также XScale, имели встроенный декодер Thumb-команд.
Набор команд Thumb-2
Thumb-2 — технология, стартовавшая с ARM1156 core, анонсированного в 2003 году. Он расширяет ограниченный 16-битный набор команд Thumb дополнительными 32-битными командами, чтобы задать набору команд дополнительную ширину. Цель Thumb-2 — достичь плотности кода, как у Thumb, и производительности, как у набора команд ARM на 32 битах. Можно сказать, что в ARMv7 эта цель была достигнута.
Thumb-2 расширяет как команды ARM, так и команды Thumb ещё большим количеством команд, включая управление битовым полем, табличное ветвление, условное исполнение. Новый язык «Unified Assembly Language» (UAL) поддерживает создание команд, как для ARM, так и для Thumb из одного и того же исходного кода. Версии Thumb на ARMv7 выглядят, как код ARM. Это требует осторожности и использования новой команды if-then, которая поддерживает исполнение до 4 последовательных команд испытываемого состояния. Во время компиляции в ARM-код она игнорируется, но во время компиляции в код Thumb-2 генерирует команды. Например:
Все кристаллы ARMv7 поддерживают набор команд Thumb-2, а некоторые кристаллы, вроде Cortex-m3, поддерживают только Thumb-2. Остальные кристаллы Cortex и ARM11 поддерживают наборы команд как Thumb-2, так и ARM.
Набор команд Jazelle
Jazelle — это технология, которая позволяет байткоду Java исполняться прямо в архитектуре ARM в качестве 3-го состояния исполнения (и набора команд) наряду с обычными командами ARM и режимом Thumb. Поддержка технологии Jazelle обозначается буквой «J» в названии процессора — например, ARMv5TEJ. Данная технология поддерживается, начиная с архитектуры ARMv6, хотя новые ядра содержат лишь ограниченные реализации, которые не поддерживают аппаратного ускорения.
ARMv8 и набор команд ARM 64 бит
В конце 2011 года была опубликована новая версия архитектуры, ARMv8. В ней появилось определение архитектуры AArch64, в которой исполняется 64-битный набор команд A64. Поддержка 32-битных команд получила название A32 и исполняется на архитектурах AArch32. Инструкции Thumb поддерживаются в режиме T32, только при использовании 32-битных архитектур. Допускается исполнение 32-битных приложений в 64-битной ОС, и запуск виртуализованной 32-битной ОС при помощи 64-битного гипервизора. [Источник 7] Applied Micro, AMD, Broadcom, Calxeda, HiSilicon, Samsung, STM и другие заявили о планах использовать ARMv8. Ядра Cortex-A53 и Cortex-A57, поддерживающие ARMv8, были представлены компанией ARM 30 октября 2012 года. [Источник 8]
Как AArch32, так и AArch64, поддерживают VFPv3, VFPv4 и advanced SIMD (NEON). Также добавлены криптографические инструкции для работы с AES, SHA-1 и SHA-256.
Функции RISC
Архитектура ARM обладает следующими особенностями RISC:
Чтобы компенсировать простой дизайн, в сравнении с современными процессорами вроде Intel 80286 или Motorola 68020 были использованы некоторые особенности дизайна:
Условное исполнение
Одно из существенных отличий архитектуры ARM (изначальная архитектура) от других архитектур ЦПУ — так называемая предикация, то есть возможность условного исполнения команд. Под «условным исполнением» здесь понимается то, что команда будет выполнена или проигнорирована в зависимости от текущего состояния флагов состояния процессора. В Thumb и Arm 64 предикация не используется — в первом режиме для неё нет места в команде (всего 16 бит), а во втором предикация бессмысленна и сложна для реализации на суперскалярных архитектурах.
В то время как для других архитектур таким свойством, как правило, обладают только команды условных переходов, в архитектуру ARM была заложена возможность условного исполнения практически любой команды. Это было достигнуто добавлением в коды их инструкций особого 4-битового поля (предиката). Одно из его значений зарезервировано на то, что инструкция должна быть выполнена безусловно, а остальные кодируют то или иное сочетание условий (флагов). С одной стороны, с учётом ограниченности общей длины инструкции, это сократило число битов, доступных для кодирования смещения в командах обращения к памяти, но с другой — позволило избавляться от инструкций ветвления при генерации кода для небольших if-блоков.
Пример, обычно рассматриваемый для иллюстрации — основанный на вычитании алгоритм Евклида. В языке C он выглядит так:
А на ассемблере ARM — так:
Из кода видно, что использование предикации позволило полностью избежать ветвления в операторах else и then. Заметим, что если Ri и Rj равны, то ни одна из SUB-инструкций не будет выполнена, полностью убирая необходимость в ветке, реализующей проверку while при каждом начале цикла, что могло быть реализовано, например, при помощи инструкции SUBLE (меньше либо равно).
Один из способов, которым уплотнённый (Thumb) код достигает большей экономии объёма — это именно удаление 4-битового предиката из всех инструкций, кроме ветвлений.
Другие особенности
Другая особенность набора команд — это возможность соединять сдвиги и вращения в инструкции «обработки информации» (арифметическую, логическую, движение регистр-регистр) так, что, например, выражение С:
может быть преобразовано в команду из одного слова и одного цикла в ARM:
Это приводит к тому, что типичные программы ARM становятся плотнее, чем обычно, с меньшим доступом к памяти. Таким образом, конвейер используется гораздо более эффективно. Даже несмотря на то, что ARM работает на скоростях, которые многие бы сочли низкими, он довольно-таки легко конкурирует с многими более сложными архитектурами ЦПУ.
ARM-процессор также имеет некоторые особенности, редко встречающиеся в других архитектурах RISC — такие, как адресация относительно счётчика команд (на самом деле счётчик команд ARM — это один из 16 регистров), а также пре- и пост-инкрементные режимы адресации.
Другая особенность, что стоит отметить, — это то, что некоторые ранние ARM-процессоры (до ARM7TDMI), например, не имеют команд для хранения 2-байтных чисел. Таким образом, строго говоря, для них невозможно сгенерировать эффективный код, который бы вел себя так, как ожидается от объектов С, типа «volatile int16_t».
Конвейер и другие аспекты реализации
ARM7 и более ранние версии имеют трехступенчатый конвейер. Это ступени переноса, декодирования и исполнения. Более производительные архитектуры, типа ARM9, имеют более сложные конвейеры. Cortex-a8 имеет 13-ступенчатый конвейер.
Сопроцессоры
Архитектура предоставляет способ расширения набора команд, используя сопроцессоры, которые могут быть адресованы, используя MCR, MRC, MRRC, MCRR и похожие команды. Пространство сопроцессора логически разбито на 16 сопроцессоров с номерами от 0 до 15, причем 15-й зарезервирован для некоторых типичных функций управления, типа управления кэш-памятью и операции блока управления памятью (на процессорах, в которых они есть).
В машинах на основе ARM периферийные устройства обычно подсоединяются к процессору путём сопоставления их физических регистров в памяти ARM или в памяти сопроцессора, или путём присоединения к шинам, которые, в свою очередь, подсоединяются к процессору. Доступ к сопроцессорам имеет большее время ожидания, поэтому некоторые периферийные устройства проектируются для доступа в обоих направлениях. В остальных случаях разработчики чипов лишь пользуются механизмом интеграции сопроцессора. Например, движок обработки изображений должен состоять из малого ядра ARM7TDMI, совмещенного с сопроцессором, который поддерживает примитивные операции по обработке элементарных кодировок HDTV.
Усовершенствованный SIMD (NEON)
Расширение усовершенствованного SIMD, также называемое технологией NEON — это комбинированный 64- и 128-битный набор команд SIMD (single instruction multiple data), который обеспечивает стандартизованное ускорение для медиаприложений и приложений обработки сигнала. NEON может выполнять декодирование аудиоформата mp3 на частоте процессора в 10 МГц, и может работать с речевым кодеком GSM AMR (adaptive multi-rate) на частоте более 13МГц. Он обладает внушительным набором команд, отдельными регистровыми файлами, и независимой системой исполнения на аппаратном уровне. NEON поддерживает 8-, 16-, 32-, 64-битную информацию целого типа, одинарной точности и с плавающей запятой, и работает в операциях SIMD по обработке аудио и видео (графика и игры). В NEON SIMD поддерживает до 16 операций единовременно.
Один из недостатков (или же особенностью) усовершенствованного SIMD — то, что сопроцессор выполняет команды усовершенствованного SIMD с достаточно значительной задержкой относительно кода основного процессора, задержка достигает двух десятков тактов и более (зависит от архитектуры и конкретных условий). По этой причине при попытке основного процессора воспользоваться результатами вычисления сопроцессора исполнение будет заморожено на значительное время.
Технология VFP (Vector Floating Point, вектора чисел с плавающей запятой) — расширение сопроцессора в архитектуре ARM. Она производит низкозатратные вычисления над числами с плавающей запятой одинарной/двойной точности, в полной мере соответствующие стандарту ANSI/IEEE Std 754—1985 Standard for Binary Floating-Point Arithmetic. VFP производит вычисления с плавающей запятой, подходящие для широкого спектра приложений — например, для КПК, смартфонов, сжатие звука, трёхмерной графики и цифрового звука, а также принтеров и телеприставок. Архитектура VFP также поддерживает исполнение коротких векторных команд. Но, поскольку процессор выполняет операции последовательно над каждым элементом вектора, то VFP нельзя назвать истинным SIMD-набором инструкций. Этот режим может быть полезен в графике и приложениях обработки сигнала, так как он позволяет уменьшить размер кода и выработку команд.
Другие сопроцессоры с плавающей запятой и/или SIMD, находящиеся в ARM-процессорах, включают в себя FPA, FPE, iwMMXt. Они обеспечивают ту же функциональность, что и VFP, но не совместимы с ним на уровне опкодов.
Расширения безопасности
Расширения безопасности, позиционируемые как TrustZone Technology, находятся в ARMv6KZ и других, более поздних, профилированных на приложениях архитектурах. Оно обеспечивает низкозатратную альтернативу добавлению специального ядра безопасности, обеспечивая 2 виртуальных процессора, поддерживаемых аппаратным контролем доступа. Это позволяет ядру приложения переключаться между двумя состояниями, называемыми «миры» (чтобы избежать путаницы с названиями возможных доменов), чтобы не допустить утечку информации из более важного мира в менее важный. Этот переключатель миров обычно ортогонален всем другим возможностям процессора. Таким образом, каждый мир может работать независимо от других миров, используя одно и то же ядро. Память и периферия соответственно изготавливаются с учетом особенностей мира ядра, и могут использовать это, чтобы получить контроль доступа к секретам и кодам ядра. Типичные приложения TrustZone Technology должны запускать полноценную операционную систему в менее важном мире, и компактный, специализированный на безопасности, код в более важном мире, позволяя Digital Rights Management’у намного точнее контролировать использование медиа на устройствах на базе ARM, и предотвращая несанкционированный доступ к устройству.
На практике же, так как конкретные детали реализации TrustZone остаются собственностью компании и не разглашаются, остается неясным, какой уровень безопасности гарантируется для этой модели угроз.
Отладка
Все современные процессоры ARM включают аппаратные средства отладки, так как без них отладчики ПО не смогли бы выполнить самые базовые операции типа остановки, отступа, установки контрольных точек после перезагрузки.
Архитектура ARMv7 определяет базовые средства отладки на архитектурном уровне. К ним относятся точки останова, точки просмотра и выполнение команд в режиме отладки. Такие средства были также доступны с модулем отладки EmbeddedICE. Поддерживаются оба режима — остановки и обзора. Реальный транспортный механизм, который используется для доступа к средствам отладки, не специфицирован архитектурно, но реализация, как правило, включает поддержку JTAG.
Существует отдельная архитектура отладки «с обзором ядра», которая не требуется архитектурно процессорами ARMv7.
Регистры
ARM предоставляет 31 регистр общего назначения разрядностью 32 бит. В зависимости от режима и состояния процессора пользователь имеет доступ только к строго определённому набору регистров. В ARM state разработчику постоянно доступны 17 регистров:
Во всех режимах, кроме User mode и System mode, доступен также Saved Program Status Register (SPSR). После возникновения исключения регистр CPSR сохраняется в SPSR. Тем самым фиксируется состояние процессора (режим, состояние; флаги арифметических, логических операций, разрешения прерываний) на момент непосредственно перед прерыванием. [Источник 9]
| usr | sys | svc | abt | und | irq | fiq |
|---|---|---|---|---|---|---|
| R0 | ||||||
| R1 | ||||||
| R2 | ||||||
| R3 | ||||||
| R4 | ||||||
| R5 | ||||||
| R6 | ||||||
| R7 | ||||||
| R8 | R8_fiq | |||||
| R9 | R9_fiq | |||||
| R10 | R10_fiq | |||||
| R11 | R11_fiq | |||||
| R12 | R12_fiq | |||||
| R13 | R13_svc | R13_abt | R13_und | R13_irq | R13_fiq | |
| R14 | R14_svc | R14_abt | R14_und | R14_irq | R14_fiq | |
| R15 | ||||||
| CPSR | ||||||
| SPSR_svc | SPSR_abt | SPSR_und | SPSR_irq | SPSR_fiq | ||
Работа с памятью
Поддерживаемые системы ввода-вывода
В большинстве существующих моделей микропроцессоров реализована шина PCI и возможность работы с внешней динамической оперативной памятью (DRAM). В процессорах, предназначенных для потребительских устройств, также обычно встраиваются: контроллеры шин USB, IIC, AC’97-совместимое звуковое устройство, устройство для работы с флэш-носителями стандарта SD и MMC, контроллер последовательного порта.
Все процессоры имеют линии ввода-вывода общего назначения (GPIO). В потребительских устройствах к ним могут быть подключены кнопки «быстрого запуска», сигнальные светодиоды, колесо прокрутки (JogDial), клавиатура.
Процесс запуска ОС на ARM-машинах
После включения системы на базе ARM-процессора, из ROM-памяти загружается начальный загрузчик и адрес его точки входа. Начальный загрузчик проводит предварительную инициализацию системы, исполняя тем самым ту же роль, которую исполняет BIOS на системах x86, после чего может загрузить либо системный загрузчик, либо напрямую ОС.
Единого стандарта на начальный загрузчик не существует: хотя современные версии стандарта UEFI предусматривают возможность реализации этого стандарта для архитектуры ARM, но на практике UEFI используется редко — большинство ОС используют собственные загрузчики, или реализуют совместимость с одним из загрузчиков других систем.
ОС, поддерживающие ARM
Архитектура ARM поддерживается множеством операционных систем. Наиболее широко используемые: Linux (в том числе Android), iOS, Windows Phone.
Работать на системах с ARM-процессором могут различные Unix и Unix-подобные ОС: Linux (многие дистрибутивы), iOS, Android, BSD (FreeBSD, NetBSD, OpenBSD), QNX, Plan 9, Inferno, OpenSolaris (2008—2009), Firefox OS.
Также на платформе запускаются отдельные варианты семейства Windows: Windows CE, Windows Phone, Windows RT, Windows 10 (только на Raspberry Pi)
Кроме того, ARM поддерживают: FreeRTOS, Nucleus, Symbian OS, RISC OS, RISC iX.
