Использование Assembler в приложениях для Motomagx, Примеры, помощь итд Поделиться Опции

[DoomChisel]

DoomChisel,
Вот что получилось
Многовато, в архиве еще пример того же самого, но под x86 и SSE2, куда красивее и приятней :)

В matrix.S набор команд, названия регистров (и пр. синтаксис) подозрительно похожи на x86
Не верю, что это - код под ARM :)

[rock88]

Не верю, что это - код под ARM :)

Действительно, что-то я через gcc делал, щас через arm-linux-gnueabi-gcc сделал

[DoomChisel]

Действительно, что-то я через gcc делал, щас через arm-linux-gnueabi-gcc сделал

Да, у меня - такая же фигня. Видать, GCC под наши ARM-ы не умеет оптимизировать с использованием векторных операций VFP (или надо его как-то по-другому собрать, или по-другому собрать и поставить какую-нибудь хитрую опцию вроде "-ftree-vectorize")
Жаль.

Кстати, под SSE2 что он выдал - там тоже с первого взгляда кажется, что не использовал векторные операции. И не все функции почему-то реализовал.

Ещё на всякий случай - есть такая опция для GCC, выдающего ассемблер - "-fverbose-asm" - всякие комменты полезные.


В-общем, переписал одну функцию на ассемблер; протестил - работает как-то.

Остальное - там разберёшься сам; например - по доку:
http://infocenter.arm.com/help/index.jsp?t...068b/index.html
Раздел "Vector Floating-point Programming"

Если надо, могу ещё подкинуть табличку про регистры ARM; reference по обычным командам процессора; cheat sheet по обычным командам процессора; док по процессору - всё с arm.com

При этом мы работаем с набором инструкций VFPv2, но он - почти такой же, как и VFPv1.

И да, сегодня узнал, что ARM в доках по неким более новым процессорам пишет, что векторные операции сопроцессора - "deprecated" :) - им там пришёл на замену некий NEON


А вот, на всякий случай, пример с inline ассемблером, работающий с VFP:
http://code.google.com/p/vfpmathlibrary/

Сообщение отредактировал DoomChisel - 25.7.2010, 19:15

[DoomChisel]

Есть успехи?

[rock88]

DoomChisel,
покa особо нe копaлся. Сeйчaс в исходникaх gpsp ковыряюсь, нa глaз - нe прaвильнaя рaботa с пaмятью, но вслeдствии чeго тaкоe происходит, из-зa нeсовмeстимости кодa нa aсмe от arm9 или eщe из-зa чeго, покa нe понял

[EXL]

DoomChisel,
Почему асм по скорости проигрывает gcc с -O3 ?
Вот для примера компилируем ZeEngine на C.



Как видим fps около 37, воспроизведение плавное и чёткое

Компилируем ту же версию ZeEngine на ARM Assembler от автора движка.

Видно, что fps ниже, он в пределе 30. И воспроизводится рывками...

Ну так вопрос: Можно ли как-нибудь оптимизировать асм код, чтобы скорость была хотя бы наравне gcc с -O3 ?

[yakk]

DoomChisel,
Ну так вопрос: Можно ли как-нибудь оптимизировать асм код, чтобы скорость была хотя бы наравне с gcc -O3?

тупо выдрать код скомпиленный C из листинга дизассемблера - получишь скорость наравне.. а оптимизировать дальше - это надо смотреть уже по коду.. в приведенном примере явно над асм кодом не особо старались..
чуть позже: просмотрел немного оба бинарника - в том который на асме очень криво реализована работа с числами с плавающей точкой - это уже источник тормозов.. хотя как по мне для этой проги можно вообще обойтись без плавающей точки - это и было бы лучшей оптимизацией )).

[DoomChisel]

Почему асм по скорости проигрывает gcc с -O3 ?

Это элементарно.

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

Компилятор же высокоуровневого языка имеет простор для оптимизации: может всё менять-удалять-переставлять; главное - чтоб не изменился результат работы программы.
А поскольку GCC - даже версии 3.4.3 - серьёзная штука, он умеет очень много в оптимизации. Однако, да - наш GCC не всегда лучшим образом использует навороты наших процессоров, в чём уже убедились в этой теме (на примере VFP.

Ну так вопрос: Можно ли как-нибудь оптимизировать асм код, чтобы скорость была хотя бы наравне с gcc -O3?

Так вот: оптимизация на ассемблере - довольно скучное дело. Там не так просто даже разобраться, как сделать, чтоб было быстрее. Не всегда это однозначно. А ещё надо именно сделать это... Плюс к тому - ещё надо определить узкое место программы, что тоже не всегда очевидно. Для этого существуют такие инструменты, как profilers.

В итоге, на сегодняшний день перегнать в оптимизации компилятор - довольно сложная штука. Поскольку тут всё непросто, мой единственный опыт по оптимизации тогда не увенчался тем, что я сделал быстрее, чем с "-o3". Я лишь сделал, чтоб было не намного медленнее

Но если кратко, ответ: скорее всего, слишком сложно.

тупо выдрать код скомпиленный C из листинга дизассемблера - получишь скорость наравне..

Это - да, но:

а оптимизировать дальше - это надо смотреть уже по коду..

Мне стрёмно как-то смотреть код после "-o3" - а уж тем более что-то там переписывать. Он ну не очень readable, тем более - maintainable
Может, yakk и умеет.

хотя как по мне для этой проги можно вообще обойтись без плавающей точки - это и было бы лучшей оптимизацией ))

Это - да. Fixed point arithmetics вместо floating point - часто даёт выигрыш. Заметь, что это - оптимизация не на ассемблере, а в коде исходной программы - на C++/C. Похоже, самый реальный вариант.