Комментарии 27
Спасибо за статью, интересно, я когда-то читал подобное, но не смог определиться с задачами. Можете описать задачи, которые вы решали, или вы бы решали при помощи ассемблера для ARM?
Я еще учусь, так что ничего серьезного не делал, но та цель ради которой я начал учить ассемблер — оптимизация аудио библиотек, вроде sox под arm. Вы бы видели сколько ассемблерных вставокв том же ffmpeg, без которых он бы сильно грузил процессор на любом arm устройстве.
Раз хотите оптимизировать цифровую обработку сигналов, глядите в сторону Neon инструкций, они позволяют выполнять многие математические операции над группой операндов. фактически можно получить ускорение в разы, если алгоритмы распараллеливаются. В NDK кстати они тоже поддерживаются. особую проблему может создать настройка среды для вывода значений регистров neon'а, но по этой теме уже есть русскоязычные статьи.
Вы, кстати, про существование orc в курсе? (см. code.entropywave.com/projects/orc/ )
Может лучше его допиливать вместо того чтоб ассемблерные вставки в библиотеках делать?
Может лучше его допиливать вместо того чтоб ассемблерные вставки в библиотеках делать?
О, новый виток развития! С нового года будет чем заниматься
Не любая инструкция может выполнятся условно, например вызов функции (bl, blx) или предзагрузка в память (pld).
С предзагрузкой, кстати есть много фокусов, типа fast memcpy, который на объёмных данных работает раза в полтора-два быстрее чем обычный.
С предзагрузкой, кстати есть много фокусов, типа 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
На самом деле вы не совсем правы в данном моменте, вы начали говорить про ARMv7(не путать с ARM7), то есть ядро Cortex M0-3-4, за 0 точно не скажу, но в M3/4 еспользуется набор инструкций Thumb-2, по сути смесь ARM+Thumb
Также, надо понимать, что удастся симулировать только работу ядра, без доступа к периферии + советую смотреть уже в сторону Cortex вместо ARM7TDMI — там более совершенная система прерываний, одна система команд + контроллер прерываний и 1 таймер входят в состав ядра(одни для всех производителей)
Спасибо за статью, как раз в универе начинаем изучать программирование ARM'ов.
Спасибо. А вот такой вопрос, чем (для программиста) отличаются ARMv4, ARMv7 и др.? Один и тот же листинг ассемблера будет адекватно компилироваться подо все эти платформы? А бинарный код совместим?
Ну. Там есть обратная совместимость для приложений.
Теоретически будет работать одинаково в разных версиях. Единственная разница — если вы будете использовать, например, NEON в ARMv6, то ничего это вам не даст, тк NEON в старых ARM нет (и в некоторых новых тоже нет). Основные инструкции, конечно будут работать везде.
Это, конечно, хорошо, что всё больше людей начинают изучать ARM (хотя, может и нет, с учётом любви вендоров лочить arm-устройства под себя), но вопрос: а с чего Вы решили, что библиотеки не оптимизированы для ARM? Вы пробовали их откомпилировать с оптимизацией, хорошим компилятором? Вроде, и Clang и GCC последних версий весьма недурно справляются с оптимизацией под ARM-ы.
Скорее всего, у Вас проблемы из-за того, что библиотеки были скомпилированы под какой-нибудь уж совсем-совсем Generic ABI, поэтому в них не используется плавающая точка или ещё что-нибудь.
Скорее всего, у Вас проблемы из-за того, что библиотеки были скомпилированы под какой-нибудь уж совсем-совсем 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-файлы) лишь автоматизируют сборку. Наверняка можно также, как в статье, руками выполнить обычную сборку с необходимыми оптимизациями.
1. Сами пишите, что сам SoX не оптимизирован под ARM. Тем более, в декодировании участвуют и ffmpeg, и другие кодеки, а это возможный источник дополнительных тормозов и пр.
2. Интересно, как смотрите нагрузку. Бинарные модули работают в окружении приложения и в top'е нагрузка указывается как от самого приложения.
3. По поводу компиляции. Средства компилирования NDK (make-файлы) лишь автоматизируют сборку. Наверняка можно также, как в статье, руками выполнить обычную сборку с необходимыми оптимизациями.
LDR r4, [r5] : r4 = *r5
STR r4, [r5] : *r5 = r4
Да как вы задрали своим Си-шным синтаксисом. Сишечка - это контекстно-зависимый язык. Вы используете куски выражений без контекста. Что из этого должен понять читатель?
Вы написали *r5. Что это значит? Какой тип вы предполагаете имеется у регистра? У регистра нет типа, это просто хранилище значения. Так что вы хотели сказать, написав *r5?
Можно с некоторой вероятностью предположить, что в регистре r5 лежит адрес ячейки, из которой значение будет загружено в r4. Но это вероятностное понимание того, что автор силился показать. Мы не знаем что на самом деле лежит в r5, мы однозначно не понимаем что означает звездочка перед регистром. Перед переменной мы бы еще могли сказать, зная тип переменной, но перед регистром - нет.
Неужели нельзя формулировать мысли так, чтобы небыло неоднозначностей? Ну хотя бы когда речь идет о языках программирования?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ARM аccемблер