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

[DoomChisel]

Собственно, есть ли у кого опыт использования ассемблера под нашу платформу?
А тот тут уже портировано много серьёзных приложений - может, где были ассемблерные вставки...
Были бы интересны исходный код, Makefile-ы.

[DoomChisel]

Были вроде, вот только не помню где именно

Ну что ж - это уже само по себе интересно )

[DoomChisel]

Да, было б хорошо для начала узнать модель процессора моей EM30...
Может, кто-нибудь в курсе, как?

Код

root:~# uname -m
armv6l
root:~# cat /proc/cpuinfo
Processor       : Some Random V6 Processor rev 1 (v6l)
BogoMIPS        : 177.34
Features        : swp half thumb fastmult vfp edsp java
CPU implementer : 0x41
CPU architecture: 6TEJ
CPU variant     : 0x1
CPU part        : 0xb36
CPU revision    : 1
Cache type      : write-back
Cache clean     : cp15 c7 ops
Cache lockdown  : format C
Cache format    : Harvard
I size          : 16384
I assoc         : 4
I line length   : 32
I sets          : 128
D size          : 16384
D assoc         : 4
D line length   : 32
D sets          : 128

Hardware        : Motorola Product - SCM-A11 Phone
Revision        : 0021
Serial          : 0000000000000000

Хмм...


Детальное описание железа(SCMA11)
Вроде как, это?..

Сообщение отредактировал DoomChisel - 28.2.2010, 20:02

[-=Strelok=-]

В исходниках ezx эмуляторов от oopsware http://oopsware.googlepages.com/ посмотри, вроде в psx было, точно не помню

[EXL]

1. gpSP точно. Именно из-за него и не могут перенести на motomagx этот чудесный эмулятор.
Как мне сказали иностранные разработчики - архитектура ARM9 и ARM11 отличается, и поэтому совместимость кода не полная.
2. В FceUltra ведро на асме.
3. В Psx4all, который скорее всего возможно перенести на A1200/E6 (Он для ARM9 написан) - асма более чем много.
4. ezxFBA в нём код оптимизирован под ARM11(9?), в итоге сумасшедшая скорость в играх (на уровне фуллспида, а может даже более..)
Это только то, что пока вспомнил, вроде кое-что кое-где было ещё.

Если нужно будет - стучи, исходниками/мэйкфайлами поделюсь

Сообщение отредактировал EXL - 13.7.2010, 16:52

[DoomChisel]

Изивините, думал, что уже все болт забили, поэтому не отписал, что уже разобрался - всё оказалось довольно просто с GNU Assembler.
Взял libJPEG, попытался оптимизировать IFAST IDCT... Собственно, в-основном только успел раскидать по регистрам переменные. Почти догнал по скорости gcc с "-g3", но не перегнал) Думаю, дело в том, что не успел заделать interleaving.
Собственно, сдал преподу и успокоился. Хотя, конечно, интересно.

psx4all

Ага, recompiler какой-то)

gpSP

Интересно - а более конкретно - в чём несовместимость?


Даже выложить особо нечего)

Единственное, в чём моё творение может представлять интерес - тестовая прога (как и изменённая libJPEG) собираются с помощью autotools. А то пока смотрю, тут autotools не любят :)


Сообщение отредактировал DoomChisel - 14.7.2010, 11:10

[EXL]

Интересно - а более конкретно - в чём несовместимость?

Я не знаю. Если кто-то скажет буду рад

[rock88]

DoomChisel,
а ты в арм асме разбираешся? А можешь тогда вот это в асм переписать? Хотябы в inline asm, вот бы круто было : )

[DoomChisel]

DoomChisel,
а ты в арм асме разбираешся? А можешь тогда вот это

matrix.zip   ( 3.46 килобайт ) Кол-во скачиваний: 200

в асм переписать? Хотябы в inline asm, вот бы круто было

Знаешь, вряд ли было б круто.
Просто если переписать, это бы вряд ли что-то ускорило. Надо ж ещё оптимизировать. И я сомневаюсь, что GCC (конечно же, с "-O3") сможет это сделать хуже, чем я. По крайней мере, в прошлом опыте, я всё же не обогнал компилятор .

Да, в нашем процессоре (по крайней мере, ARM1136JF-S на EM30) должен быть "Vector Floating-Point (VFP)" unit, хорошо предназначенный как раз для векторных вычислений: "The VFP implements the ARM VFPv2 floating point coprocessor instruction set. It supports single and double-precision arithmetic on vector-vector, vector-scalar, and scalar-scalar data sets.". ( С ним не работал. )

Далее, получить в файлик ассемблерный код, сгенерированный GCC, можно с помощью опции "-S": "Stop after the stage of compilation proper; do not assemble. The output is in the form of an assembler code file for each non-assembler input file specified."
Если в выходном ассемблерном файле, скомпиленном с "-O3" из данного "matrix.cpp" активно используются всякие операции VFP unit с векторами, - мне кажется, что в таком случае соптимизировалось хорошо, и вряд ли что-то тут можно придумать)

И извините - самому мне сейчас что-то программировать не за деньги - лето/лень/нет времени
А то бы, конечно, - много чего хочется написать...

И да - весь этот ассемблер осваивается очень быстро.

В-общем, думаю, скомпиль файлик с оптимизацией - ну и если хочешь, покажи мне - оценю, что вышло. Хотя, наверное, должно быть что-то нифиганепонятное на "-O3" )

Ещё что можно сделать - узнать, какое именно устройство эмулируется в DeSmuME с использованием "matrix.cpp" - спросить у разработчиков эмулятора, например; и поискать в инете что-нибудь для его эмуляции, оптимизированное под ARM. Это, конечно, не очень вероятно, что даст результат - но мало ли...

[rock88]

DoomChisel,
Вот что получилось

matrix_asm.zip   ( 4.49 килобайт ) Кол-во скачиваний: 212

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

[DoomChisel]

DoomChisel,
Вот что получилось

matrix_asm.zip   ( 4.49 килобайт ) Кол-во скачиваний: 212

Многовато, в архиве еще пример того же самого, но под 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. Похоже, самый реальный вариант.