Попробую... Да одна такая таблица получается) это для 64 гармоники при частоте дискретизации 250килосемплов/секунду (реальная частота 63500Гц), но надо ещё +8 частот смотреть... поэтому менять думаю особо невариант

Перед тем как оптимизировать на асме, разберитесь сначала с оптимизацией ни СИ. Во-первых, при оптимизации на асме можно сделать очепятку, которую потом будете долго и упорно искать. Во-вторых, оптимизация на Си выполняется гораздо быстрее. В-третьих, при хорошо изученном поведении своего компилятора, отимизированный код на Си будет всего на 5...15% больше своего собрата на асме, зато скока сэкономленого времени?!
И если только оптимизация на Си не помогает, то необходимо залезать в ассемблер.
Но и при ассемблерной оптимизации есть куча подводных камней.

Примеры:
1. Использование указателей вместо индексации массивов

Это сокращает код на одно вычисление адреса Values[CurVal]. FsummIm и FsummRe, FsinTable и FcosTable также можно привести к использованию указателей

2. Оптимизация циклов.
Цикл i=N;do{.....}while(i--); в большинстве случаев более оптимизировано компилируется, чем цикл for(i = 0; i < N; i++){........};

3. При целочисленной арифметике, деление заменяется на умножение и сдвиг.
4. Объявление наиболее используемых локальных переменных как register (не вовсех компиляторах)
5. и т.д. и т.п..........................

Спасибо! Весьма полезные советы!!!

На достаточном уровне оптимизации (-О3 достаточно) gcc это все сделает сам. (Хотя в конверсии массивов в указатели может и запутаться - у вас там весьма накрученно массивы индексируются)

1. Поверьте мне - GCC НЕ ВСЕ ЭТО сделает сам, в нем заложены только типичные алгоритмы, которые впрочем постоянно расширяются и периодически обновляются.
2. Мои высказывания относятся ко всем компиляторам, а не только к GCC. И если писать сразу отпимизировано, то не надо будет думать, что "я это делать не буду - это компилятор САМ прооптимизирует", а потом локти себе кусать. Это путь к деградации, если думать что за тебя все сделает компилятор/оптимизатор.
3. -О3 конечно хорошо, но когда идет отладка, то -О3 отключаешь, и как раз в этот момент не хватает - то оперативки, то флеша, то быстродействия......... (если конечно при проектировании не заложили запас, а все сделали в притык, как часто бывает)

Да там индексы не нужны вообще. Например, здесь

FsummRe[FreqNum] += Values[i]*cosVal;

дважды по 256 раз вычисляется адрес по индексу FreqNum, но этот индекс - константа в подпрограмме.

Надо бы поставить A=A+Values[i]*cosVal;

в теле цикла, а после цикла сделать обратное присвоение FsummRe[FreqNum]=А

Возник следующий вопрос - как в на асме прочитать байтик из памяти программ? Покопавшись в просторах интернета нашёл следующее:


F64_cos - таблица значений косинуса. Но чёт это не работает. Код в AVR stidio 4 помнется выглядит примерно так:

Т.е. в AVR stidio 4 нужно делать сдвиг в лево, что равно умножению на 2. Почитав доки на avr-gcc нашёл что макрос pm надо использовать если нужен доступ к памяти программ, но он равносилен деления на 2 или, что тоже самое, сдвигу на 1 в право. На этом моменте у меня сразу возникло не понимание принципа доступа к памяти программ на ассемблере в avr-gcc.
Может кто в курсе как делается правильно?

Вот весь код на асме, который написал:


Нашел в чём проблема, мой косяк, F64_cos была в ОЗУ. И собственно чтоб прочитать из памяти программ нужно:
ldi ZH, hi8(F64_cos)
ldi ZL, lo8(F64_cos)
lpm r18, Z
без всяких макросов pm().
И новый вопрос: я правильно понимаю, макрос pm() используется для вызова подпрограмм, например:
ldi ZH, hi8(pm(s_func))
ldi ZL, lo8(pm(s_func))
call Z
так?

1. pm не используется для вызова подпрограм. Для вызова подпрограмм используются команды CALL/ICALL/EICALL/RCALL.
pm() - program memory, макрос просто умножает параметр на 2.
Дело в том, что ОЗУ у AVR адресуется байтово, а flash-память словарно, и адреса всех объектов, лежащих во flash-памяти являются словарными. Поэтому что бы из словарного адреса получить байтовый (для доступа к любому байту flash-памяти), необходимо умножить на 2, или сдвинуть на 1 влево.

Доступ к flash-памяти:


2. call Z - нет такой команды, есть icall.
И насколько я помню при загрузке ZH:ZL для команды icall, сдвигать адрес не надо.
Косвенный вызов функции:



Сообщение отредактировал alexeyv - Apr 9 2012, 04:11

Вообще то, при постановке вопроса следовало бы уточнить, а какая собственно оптимизация вам нужна ? По скорости или по объему ? Подходы к обоим видам совершенно разные, кроме как совета писать на асме. Без этого бессмысленно что либо советовать.

Сообщение отредактировал fox2trot - Apr 12 2012, 16:43