Программа на ассемблере для ARM Опции

[Иван_Я]

Подскажите пожалуйста возможно ли на ассемблере написать программку для ядра ARM ? В даташитах даже не указывается время выполнения команды...?... (Необходимо создать недорогое, но быстрое приложение. Поэтому нужна программа на ассемблере).

[KAlex]

Возможно.
Время выполнения зависит от тактовой ядра.
(???)

[richie]

Не факт, что написанный человеком ассемблерный код будет эффективнее сгенерированного оптимизирующим многопроходным компилятором.

[MrYuran]

В даташитах даже не указывается время выполнения команды...?...

AVR32 != ARM
(это я по поводу темы-близнеца)

[_Pasha]

AVR32 != ARM
(это я по поводу темы-близнеца)

За кросспостинг вааще надо как-то бить

По теме: замечено, что в случае с ARM от любого сишного компилятора оторваться в плане эффективности кода очень тяжело. 

[GetSmart]

По теме: замечено, что в случае с ARM от любого сишного компилятора оторваться в плане эффективности кода очень тяжело. 

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

[_Pasha]

Некоторые алгоритмы (циклы и прочее) можно написать на асме со скоростью исполнения в несколько раз быстрее.

Отожрать при этом регистры, коих и так мало. 

[GetSmart]

Отожрать при этом регистры, коих и так мало. 

Сколько жадине не давай, ему всегда мало
Неуж то сложно сохранить всё ненужное в стеке, а на выходе восстановить?

[_Pasha]

Неуж то сложно сохранить всё ненужное в стеке, а на выходе восстановить?

Тогда получится Си

[Иван_Я]

AVR32 != ARM
(это я по поводу темы-близнеца)

Это я понял. У меня есть и АРМ и АВР32. и вопросы я поднял по теме. так что сам написал, что они не равны.

по теме: Дело в том, что с АВР8 понятно там есть время такта и все команды привязаны к тактам (в основном 1 к 1). а что в АРМ, что АВР 32 не понятно вообще. и Потом, что касается программы на Си - на ней компилятор создает машиный код, но как посчитать например время выполнения одного цикла ПИД алгоритма? на асе как-то понятно. знаешь сколько тактов выполняется команда и уже можешь оценить время выполнения одного цикла того или иного алгоритма....

может быть у кого есть простейшие примеры для АРМ (АВР32) на языке ассемблера). поделитесь пожалуйста.

[_Pasha]

но как посчитать например время выполнения одного цикла ПИД алгоритма?

У Вас длительность процесса приближается к интервалу его вызова?

[scifi]

В даташитах даже не указывается время выполнения команды...?...

Не знаю, как другие ARMы, а для ARM7TDMI есть такой документ Technical Reference Manual, в котором есть глава Instruction Cycle timings. Конечно, в отдельно взятом МК надо учитывать, как процессор цепляется к памяти и периферии.

Потом, что касается программы на Си - на ней компилятор создает машиный код, но как посчитать например время выполнения одного цикла ПИД алгоритма?

Зачем это считать? Для получения нужной периодичности есть таймеры. Считать циклы - это лишняя головная боль и потенциальное минное поле.

[sergeeff]

Складывается впечатление, что автор текущей ветки не с той стороны заходит на решение поставленной перед ним задачи. И уж, конечно, подсчеты тактов на выполнение - не вариант, про это неоднократно на форуме говорилось.

[Иван_Я]

Складывается впечатление, что автор текущей ветки не с той стороны заходит на решение поставленной перед ним задачи. И уж, конечно, подсчеты тактов на выполнение - не вариант, про это неоднократно на форуме говорилось.

Обычно перед созданием программы оценивают возможности процессора. Если стоит задача работы в реальном времени (а у меня все такие задачи), то подсчет тактов очень важен.

При управлении векторном есть такое понятие как разложение на dq составляющие. Смотрел в документации на ТМС20хх... там есть пример на ассемблере как это разложение произвести. Но к сожалению нет возможности приобрести отладку для данного проца ( а в наличии есть АРМ LPC и АВР32 распаянный на плате NGW100) (задача реализации в лабораторных условиях и учебных целей).
Короче необходимо выполнять в основном арифметические операции, поэтому и требуется ассемблер.

У Вас длительность процесса приближается к интервалу его вызова?

Да скорее всего так и будет. Просто хочется сделать запас определенный. ВОт этого я и бось - что длительность одного цикла обсчета приблизится к времени отсчета данных АЦП. Причем не обязательно будет использоваться именно ПИД алгоритм, еще есть цель реализовать dq преобразование... вычисление синуса и косинуса.. Поэтому в основном мне и нужен ассемблер. (Я в учебных целях. Есть большое желание реализовать dq преобразование).

[sergeeff]

А если надо работать в нереальном времени? Шутка.

Никак не пойму, причем здесь выполнение арифметических операций и программирование на ассемблере?

Что такое программирование в реальном времени? Надо обрабатывать высокочастотные процессы? А почему "в учебных целях" нельзя обрабатывать низкочастотные процессы?

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

А какова частота опроса ADC?

[defunct]

Да скорее всего так и будет. Просто хочется сделать запас определенный. ВОт этого я и бось - что длительность одного цикла обсчета приблизится к времени отсчета данных АЦП. Причем не обязательно будет использоваться именно ПИД алгоритм, еще есть цель реализовать dq преобразование... вычисление синуса и косинуса.. Поэтому в основном мне и нужен ассемблер. (Я в учебных целях. Есть большое желание реализовать dq преобразование).

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

На каком языке пользовать аппаратные возможности - нет разницы, особенно для математики. Скорость упирается в возможности железа.

А про эффективность и удобство языков хорошо сказано здесь:

http://tempo.nnm.ru/kak_prostrelit_sebe_nogu

По-русски это удобство превращается вот во что:
1. или написать
y = sin( x );
и заниматься неделю чем-то полезным, и к тому же быть спокойным, что эта же строчка сразу же заработает на любом другом процессоре.

2. или неделю промудохаться над реализацией одной только этой строчки на АСМ.

Потом, что касается программы на Си - на ней компилятор создает машиный код, но как посчитать например время выполнения одного цикла ПИД алгоритма?

Элементарно - с помощью обычного секундомера:

Засечь время, запустить 1 млн циклов, затем разделить полученный интервал времени на млн. - получите время на цикл.
не нравится 1 млн. (тест длится сильно долго или сильно быстро) измените это число.

Помоему это очевидно.

Если стоит задача работы в реальном времени (а у меня все такие задачи), то подсчет тактов очень важен.

На самом деле не важен, просто закладывайте проц с запасом.
(если пользоваться правилом - всегда закладывать проц с 50% запасом, то достаточно очень грубой оценки производительности - те самые +/-50%)

Вот Вы говорите у Вас сейчас есть AVR32 (150Mhz) и LPC ARM ~60Mhz.
У первого есть набор DSP инструкций, у второго такого набора нет. Разница по производительности более чем 2.5 раза. А цена - практически одинаковая.
Так какой смысл такты считать?

[Иван_Я]

А если надо работать в нереальном времени? Шутка.

Никак не пойму, причем здесь выполнение арифметических операций и программирование на ассемблере?

Что такое программирование в реальном времени? Надо обрабатывать высокочастотные процессы? А почему "в учебных целях" нельзя обрабатывать низкочастотные процессы?

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

А какова частота опроса ADC?

) да нет) надо обрабатывать сигналы промышленной частоты (50 Гц). на счет частоты опроса - миимальное количество точек на период - 64.

ну да.. можно конечно и на практике оценить...


ps: Вы извините, если какие-нибудь выражения звучат не так, как может быть следовало... дело в том, что этим занимаюсь впервые.. и с работы с процессорами нет большого опыта.

[quote name='sergeeff' date='Feb 13 2009, 01:29' post='545527']
А если надо работать в нереальном времени? Шутка.

Никак не пойму, причем здесь выполнение арифметических операций и программирование на ассемблере?

Везде говорят, что выполнение программы на Ассемблере сокращает вермя ее выполнения раза в 2. Поэтому и Ассемблер.

И потом, ладно, написали программу на Си, а как вести отладку в дизассемблере, если не знать Ассемблер данного проца. Ведь чтобы написать оптимизированную программу даже на СИ надо знать все особенности данного проц. в том числе и его систему команд на Ассемблере.

[scifi]

Первое суеверие победили, отлично :-) Осталось победить остальные.

Везде говорят, что выполнение программы на Ассемблере сокращает вермя ее выполнения раза в 2. Поэтому и Ассемблер.

Не нужно верить всему, что говорят. Тут очень многое зависит от конкретной ситуации.

И потом, ладно, написали программу на Си, а как вести отладку в дизассемблере, если не знать Ассемблер данного проца.

Вы удивитесь: подавляющее большинство программистов процессора x86 не знают его ассемблера и не переживают по этому поводу. Пишут программы на Си и Си++, отлаживают их и не знают печали.
Хотя в Embedded, конечно, ситуация несколько иная. Я частенько заглядываю в дизассемблер, иногда и глюки компилятора выскакивают... Но такты процессора точно не считаю.

Ведь чтобы написать оптимизированную программу даже на СИ надо знать все особенности данного проц. в том числе и его систему команд на Ассемблере.

Мне кажется, Вы не с того начинаете. Ведь задача стоит не "написать оптимизированную программу", а "написать работающую программу". Помните слова уважаемого человека Дональда Кнута: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." ("Нам следует забывать о малых оптимизациях, скажем, 97% времени: преждевременная оптимизация - корень всех зол")

[WDT]

Элементарно - с помощью обычного секундомера:

Засечь время, запустить 1 млн циклов, затем разделить полученный интервал времени на млн. - получите время на цикл.
не нравится 1 млн. (тест длится сильно долго или сильно быстро) измените это число.

Помоему это очевидно.

Не факт... Попробуйте сами так сделать...

Вот Вы говорите у Вас сейчас есть AVR32 (150Mhz) и LPC ARM ~60Mhz.
У первого есть набор DSP инструкций, у второго такого набора нет. Разница по производительности более чем 2.5 раза. А цена - практически одинаковая.
Так какой смысл такты считать?

С чего это цена одинаковая? Как минимум в три раза разница.

Мне думается, автор темы не пока не совсем представляет чего он сам хочет сделать и в процессе этих разговоров стимулирует МЫСЛИТЕЛЬНЫЕ процессы...

[Иван_Я]

Я представляю что надо сделать и я об этом писал уже. Надо реализовать ЦОС dq преобразование. Примеры есть от Texas на ассемблере. Был и есть интерес реализовать этот же алгоритм на LPC или AVR32 с учетом их специфики и систем команд. Я понял,что на Ассемблере писать можно. Всем спасибо за свои предложения.

Сообщение отредактировал Иван_Я - Feb 13 2009, 07:30

[sergeeff]

Вы бы взяли ассемблерный пример от Texas, реализовали его на С и попробовали на обоих, имеющихся в вашем распоряжении платформах. Времени на все это уйдет - не сопоставимо меньше, по сравнению с писанием всего на ассемблере. К тому же, отвяжетесь от конкретной платформы и будете устремлены в будущее.

[MrYuran]

Я понял,что на Ассемблере писать можно. Всем спасибо за свои предложения.

Но не нужно.
Алгоритм такой:
1. Пишете и отлаживаете алгоритм на си.
2. Если всё устраивает - конец, задача решена.
3. Оптимизируете узкие места.
4. goto 2
5. Если по-другому никак не получается, особо критичные места перекладываете на асм.

[defunct]

Не факт... Попробуйте сами так сделать...

Разве бы я советовал то в чем не был уверен или то что никогда не пробовал?
Всегда так и оцениваю. Разве только секундомер с требуемой точностью/разрешением реализую в той же программе:

Код

starttime = GetTime();

for( n = N; n; n--)
    f(n);

duration = GetTime() - starttime;
f_time = duration / N;

С чего это цена одинаковая? Как минимум в три раза разница.

Смотря с чем сравнивать. Если с МК с ARM ядром и такой же периферией как в AP7000 то цена будет примерно одинаковой.
А если брать что NGW100 от производителя - $50.
плата с любым LPC в той же конфигурации будет не дешевле. Отсюда вывод о цене.

[kons]

Ассемблер ARM (не в Thumb варианте) - вообще самый гуманный из ассемблеров, и по простоте может сравниться только с asm PDP11, но с тем всерьез не работал. По опыту, всякие FIR, корреляторы и т.п., написанные под ARM7 на asm могут работать раз в 5-10 быстрее написанных на с. Кстати, подобные вещи и для нормальных DSP поставляются тоже в виде библиотек на asm - только так можно всерьез задействовать все "фишки" процессора типа 2-4 MAC за такт и т.д.

Обоснование типа "нужна быстрая математика поэтому - ассемблер" - бредовое.
Вообще-то если нужна быстрая математика брать нужно проц (DSP) где есть реализованные аппаратно требующиеся мат. функции - например проц где синус вычисляется за такт и т.п..

Оно так, оно конечно...Но если вы мне подскажете DSP-однокристалку в TQFP-68, max 100, чтобы у нее все было на борту, архитектура не убогая (не DSPIC), и по цене как SAM7 (TI при тех же RAM/FLASH дороговаты), я буду благодарен. Подумайте, если задача вписывается в 5 DSP-шных MIPS (это 30-50 ARM-овских), то...почему бы и не ARM? Тем более, что в реальности на asm требуется написать только маленькую библиотечку.

Но в случае автора:

надо обрабатывать сигналы промышленной частоты (50 Гц). на счет частоты опроса - миимальное количество точек на период - 64.

Есть глубокое подозрение (опять же по опыту ЦОС на ARM), что при частоте дискретизации 3200 Гц можно прекрасно обойтись без asm модулей.

[_Pasha]

архитектура не убогая (не DSPIC)

Убогая или наоборот - а заточена как раз на эти задачи, т.е то, что автору надо.  А на асме эти модули потому, что MAC-инструкции имеют столько "побочных эффектов", что не ложатся в квадратную голову компиляторов. Так и смысла нету в высокоуровневом программировании - все равно в матричных операциях не будет архисложностей. Меня самого сначала раздражало то, что во всех Сях для DSPIC невозможно добиться от компилера использования DSP-класса инструкций "не по назначению". Теперь - абсолютно все равно. Кесарю-кесарево, слесарю-слесарево.