Обоснование типа "нужна быстрая математика поэтому - ассемблер" - бредовое.
Вообще-то если нужна быстрая математика брать нужно проц (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 раза. А цена - практически одинаковая.
Так какой смысл такты считать?

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

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


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

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

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

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

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

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


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


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


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

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


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

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

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

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

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

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

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




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

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


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

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

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

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