Comments 26
Спасибо за статью, интересно, я когда-то читал подобное, но не смог определиться с задачами. Можете описать задачи, которые вы решали, или вы бы решали при помощи ассемблера для ARM?
Я еще учусь, так что ничего серьезного не делал, но та цель ради которой я начал учить ассемблер — оптимизация аудио библиотек, вроде sox под arm. Вы бы видели сколько ассемблерных вставокв том же ffmpeg, без которых он бы сильно грузил процессор на любом arm устройстве.
Раз хотите оптимизировать цифровую обработку сигналов, глядите в сторону Neon инструкций, они позволяют выполнять многие математические операции над группой операндов. фактически можно получить ускорение в разы, если алгоритмы распараллеливаются. В NDK кстати они тоже поддерживаются. особую проблему может создать настройка среды для вывода значений регистров neon'а, но по этой теме уже есть русскоязычные статьи.
Да, спасибо я об этом слышал. Сначала разберусь с основами арм ассемблера вообще, чтоя уже делаю, а потом займусь неон. Может и статья выйдет новая:)
О, новый виток развития! С нового года будет чем заниматься
Не любая инструкция может выполнятся условно, например вызов функции (bl, blx) или предзагрузка в память (pld).
С предзагрузкой, кстати есть много фокусов, типа fast memcpy, который на объёмных данных работает раза в полтора-два быстрее чем обычный.
Спасибо, познавательная статья. Тоже Java программист, кстати. Junior.
Спасибо за статью, ассемблер ARM у меня наверное самый любимый.
Архитектура развивалась с течением времени, и начиная с ARMv7 были определены 3 профиля: ‘A’(application) — приложения, ‘R’(real time) — в реальном времени,’M’(microcontroller) — микроконтроллер. Историю разработки этой технологии и другие интересный данные вы можете прочитать в Википедии или погуглив в интернете. ARM поддерживает разные режимы работы (в основном Thumb и ARM).

На самом деле вы не совсем правы в данном моменте, вы начали говорить про ARMv7(не путать с ARM7), то есть ядро Cortex M0-3-4, за 0 точно не скажу, но в M3/4 еспользуется набор инструкций Thumb-2, по сути смесь ARM+Thumb
Также, надо понимать, что удастся симулировать только работу ядра, без доступа к периферии + советую смотреть уже в сторону Cortex вместо ARM7TDMI — там более совершенная система прерываний, одна система команд + контроллер прерываний и 1 таймер входят в состав ядра(одни для всех производителей)
>Также, надо понимать, что удастся симулировать только работу ядра

Да, это ясно. Я вообще думаю в дальнейшем, если хорошо разбирусь, использовать это для оптимизации библиотек, которые я использую в Android NDK (думаю из статьи понятно:), так что там с периферией разберусь.
Спасибо за статью, как раз в универе начинаем изучать программирование ARM'ов.
Спасибо. А вот такой вопрос, чем (для программиста) отличаются ARMv4, ARMv7 и др.? Один и тот же листинг ассемблера будет адекватно компилироваться подо все эти платформы? А бинарный код совместим?
Теоретически будет работать одинаково в разных версиях. Единственная разница — если вы будете использовать, например, NEON в ARMv6, то ничего это вам не даст, тк NEON в старых ARM нет (и в некоторых новых тоже нет). Основные инструкции, конечно будут работать везде.
Это, конечно, хорошо, что всё больше людей начинают изучать ARM (хотя, может и нет, с учётом любви вендоров лочить arm-устройства под себя), но вопрос: а с чего Вы решили, что библиотеки не оптимизированы для ARM? Вы пробовали их откомпилировать с оптимизацией, хорошим компилятором? Вроде, и Clang и GCC последних версий весьма недурно справляются с оптимизацией под ARM-ы.

Скорее всего, у Вас проблемы из-за того, что библиотеки были скомпилированы под какой-нибудь уж совсем-совсем Generic ABI, поэтому в них не используется плавающая точка или ещё что-нибудь.
Вообще я не уверен, что эта библиотека под ARM не оптимизирована, но у меня не получилось ее собрать так, чтобы она не гразилда процессор до 80-90%, да и плюс к тому, как я уже писал — я пеисал под Android, а в нем сборка библиотек идет через Android NDK, поэтому я не могу использовать другие компиляторы (я так думаю, если ошибаюсь — поправьте).

А насчет изучения — в любом случае это интернесно, так что время, я считаю, зря не потратил:)
В NDK можно отдельно компилировать под ARMv6 и ARMv7, соответственно, с разными оптимизациями (NEON тот же, и пр). Хотя думаю, уж в курсе. Просто странно, что результат не устроил. Может, в коде дело?)
Да, я пробовал оба варианта. Тестировал на Samsung galaxy tab. Если интересно, я писал статью об этом. Вот: habrahabr.ru/blogs/android_development/131377/. Можете сами пропробовать. Конечно есть вероятность, что я сделал что-то не верно, но я больше склоняюсь к тому, что SoX действительно не оптимизирован (а кроме него еще и стопка кодеков, так как этот самый SoX использует штук 10 библиотек, хотя проще было бы одним FFmpeg'ом все декодиить).
Статью читал, позже из интереса попробую собрать и проверить у себя, но это будет явно в следующем году.
1. Сами пишите, что сам SoX не оптимизирован под ARM. Тем более, в декодировании участвуют и ffmpeg, и другие кодеки, а это возможный источник дополнительных тормозов и пр.
2. Интересно, как смотрите нагрузку. Бинарные модули работают в окружении приложения и в top'е нагрузка указывается как от самого приложения.
3. По поводу компиляции. Средства компилирования NDK (make-файлы) лишь автоматизируют сборку. Наверняка можно также, как в статье, руками выполнить обычную сборку с необходимыми оптимизациями.
Only those users with full accounts are able to leave comments. Log in, please.