Использование Assembler в приложениях для Motomagx, Примеры, помощь итд |
Здравствуйте, гость ( Вход | Регистрация ) |
Использование Assembler в приложениях для Motomagx, Примеры, помощь итд |
DoomChisel |
23.7.2010, 8:33
|
Интересующийся Группа: Пользователи Сообщений: 97 Регистрация: 7.7.2008 Из: СПб Пользователь №: 176 527 Модель телефона: Motorola EM30 Прошивка: PerfectMod 08.08.09 Рейтинг: 42.5 |
|
rock88 |
23.7.2010, 13:22
|
|
Мастер Группа: Пользователи Сообщений: 209 Регистрация: 26.6.2009 Из: г. Омск Пользователь №: 201 900 Модель телефона: L9 & EM30 Прошивка: 05R & 04.06R Рейтинг: 584 |
| |
DoomChisel |
25.7.2010, 19:10
|
|
Интересующийся Группа: Пользователи Сообщений: 97 Регистрация: 7.7.2008 Из: СПб Пользователь №: 176 527 Модель телефона: Motorola EM30 Прошивка: PerfectMod 08.08.09 Рейтинг: 42.5 |
Действительно, что-то я через 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 |
7.8.2010, 17:12
|
Интересующийся Группа: Пользователи Сообщений: 97 Регистрация: 7.7.2008 Из: СПб Пользователь №: 176 527 Модель телефона: Motorola EM30 Прошивка: PerfectMod 08.08.09 Рейтинг: 42.5 |
Есть успехи?
|
rock88 |
9.8.2010, 14:10
|
Мастер Группа: Пользователи Сообщений: 209 Регистрация: 26.6.2009 Из: г. Омск Пользователь №: 201 900 Модель телефона: L9 & EM30 Прошивка: 05R & 04.06R Рейтинг: 584 |
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 |
25.9.2010, 13:23
|
|||
Rock The Microphone Группа: Администраторы Сообщений: 3 025 Регистрация: 12.5.2007 Из: г. Новосибирск Пользователь №: 134 652 Модель телефона: XT894 / XT897 Прошивка: Различные Настроение: null Рейтинг: 4622.5 |
DoomChisel,
Почему асм по скорости проигрывает gcc с -O3 ? Вот для примера компилируем ZeEngine на C. Как видим fps около 37, воспроизведение плавное и чёткое Компилируем ту же версию ZeEngine на ARM Assembler от автора движка. Видно, что fps ниже, он в пределе 30. И воспроизводится рывками... Ну так вопрос: Можно ли как-нибудь оптимизировать асм код, чтобы скорость была хотя бы наравне gcc с -O3 ?
| |||
yakk |
26.9.2010, 1:57
|
Группа: Разработчики Сообщений: 336 Регистрация: 6.7.2006 Из: Днепропетровск Пользователь №: 90 408 Модель телефона: milestone Настроение: не нужен.. Рейтинг: 904 |
DoomChisel, Ну так вопрос: Можно ли как-нибудь оптимизировать асм код, чтобы скорость была хотя бы наравне с gcc -O3? тупо выдрать код скомпиленный C из листинга дизассемблера - получишь скорость наравне.. а оптимизировать дальше - это надо смотреть уже по коду.. в приведенном примере явно над асм кодом не особо старались.. чуть позже: просмотрел немного оба бинарника - в том который на асме очень криво реализована работа с числами с плавающей точкой - это уже источник тормозов.. хотя как по мне для этой проги можно вообще обойтись без плавающей точки - это и было бы лучшей оптимизацией )). |
DoomChisel |
27.9.2010, 15:15
|
Интересующийся Группа: Пользователи Сообщений: 97 Регистрация: 7.7.2008 Из: СПб Пользователь №: 176 527 Модель телефона: Motorola EM30 Прошивка: PerfectMod 08.08.09 Рейтинг: 42.5 |
Почему асм по скорости проигрывает gcc с -O3 ? Это элементарно. Когда компилируешь (или как там - ассемблируешь) ассемблерный код - сам ассемблер уже не может сделать никаких оптимизаций - он (нуу почти) собирает всё по порядку, один в один как написано в ассемблерном исходнике. Компилятор же высокоуровневого языка имеет простор для оптимизации: может всё менять-удалять-переставлять; главное - чтоб не изменился результат работы программы. А поскольку GCC - даже версии 3.4.3 - серьёзная штука, он умеет очень много в оптимизации. Однако, да - наш GCC не всегда лучшим образом использует навороты наших процессоров, в чём уже убедились в этой теме (на примере VFP. Ну так вопрос: Можно ли как-нибудь оптимизировать асм код, чтобы скорость была хотя бы наравне с gcc -O3? Так вот: оптимизация на ассемблере - довольно скучное дело. Там не так просто даже разобраться, как сделать, чтоб было быстрее. Не всегда это однозначно. А ещё надо именно сделать это... Плюс к тому - ещё надо определить узкое место программы, что тоже не всегда очевидно. Для этого существуют такие инструменты, как profilers. В итоге, на сегодняшний день перегнать в оптимизации компилятор - довольно сложная штука. Поскольку тут всё непросто, мой единственный опыт по оптимизации тогда не увенчался тем, что я сделал быстрее, чем с "-o3". Я лишь сделал, чтоб было не намного медленнее Но если кратко, ответ: скорее всего, слишком сложно. тупо выдрать код скомпиленный C из листинга дизассемблера - получишь скорость наравне.. Это - да, но: а оптимизировать дальше - это надо смотреть уже по коду.. Мне стрёмно как-то смотреть код после "-o3" - а уж тем более что-то там переписывать. Он ну не очень readable, тем более - maintainable Может, yakk и умеет. хотя как по мне для этой проги можно вообще обойтись без плавающей точки - это и было бы лучшей оптимизацией )) Это - да. Fixed point arithmetics вместо floating point - часто даёт выигрыш. Заметь, что это - оптимизация не на ассемблере, а в коде исходной программы - на C++/C. Похоже, самый реальный вариант. |
Текстовая версия | Сейчас: 21.9.2024, 4:17 |
Форум живёт: