Ну так вы предложение до конца дочитайте. Восьмибитные там значило, что на 16-битных операндах скорость будет меньше на порядок, а на 32-битных - на два порядка. Это чтобы человек 20 мипсами не обольщался.


Нормально. При условии, что включал бы и выключал свет, когда его попросят, а не когда попало, и не с десятой попытки, и звонил бы васе, а не пете. А не так, как в двух выше приведенных ссылках - в одной надежно распознаются только три команды, а во второй - слово "да" и только в условиях тишины. Ну т.е. мне совершенно не нужен выключатель, который перестает работать, когда у меня включена музыка или телевизор. А если он еще команды телевизора начнет исполнять, вообще будет смешно несмешно.

Для подавляющего большинства операций (сложение, сдвиг, сравнение, копирование) - ровно в два раза. Для умножения чуть больше в 3-5 раз. Для некоторых операций скорость даже выросла (напр мастабирование - деление на 2^8 будет быстрее т.к. не нужно делать &).

Так откуда взялась разница на порядок?


Тогда уж лучше обычный комп. Пусть распознает и раздает мелким девайсам команды.

Распишите на AVR умножение двух 16-битных операндов. Двух 32-битных операндов. (Можно подсмотреть, например у GCC)


Вместо выключателя по компу ? Однако...

32-х битные расписывать не буду, нет смысла. Вначале надо разобраться с 16x.
Решение тупо в лоб:



С ограничениями - произведение не может быть больше 65535.
итого 12 тактов против 2. (в 6 раз, однако не на порядок).
Таблично можно сделать быстрее.


Вы предлагаете вместо каждого выключателя по DSP. А я предлагаю 1 комп вместо всех выключателей.

Точно. Давно не брал в руки своего Осла, подзабыл уже. Но помнится мне, что в весьма он недолго занимался постобработкой. Все таки надо посмотреть, как он это делает, может натолкнет на какие-нибудь мысли.


Ну или один матерый ДСП. Идея - зачот

Обычно не долго, поскольку обработка идет уже и при записи слова, НО важнее, что по отмашке, а не постоянно анализируя поток.

Ну так сколько чернил для шестнадцатого класса выдавливается из AVR ?


А думать пробовали ? )


Я комп даже на лампочку в туалет не поставлю. Ну мало ли прижмет срочно, а будешь полчаса упрашивать свой выключатель, как дурак, свет включить )



По отмашке идет _только_ обработка словаря. Это можно и на PC сделать. Да хоть на крейе каком-нибудь. А вот разбор команд - в реалтайм, как ни крути, без отмашек, в шуме и с прочими прелестями.

но не на порядок же больше чем для восьмого. log2 != log10.


А что, смущает размер таблицы? да многовато.. ;> ну можно умножитель на CPLD прикрутить
дорого, но тем не менее потенциальная возможность ускорить с 12 до 6-ти тактов (4xOUT / 2xIN ) или 8-ми тактов (2xOUT, 2xLD) есть.


Главное винду не ставить ;>

Если с такими ограничениями, то последние две инструкции не нужны
Так что минус три такта, остаётся 9.

А вообще, добавлять ro к CH это ошибка. Добавлять надо к третьему байту, которого в вашем случае нет.

Да да!
Спасибо что заметили. Итого 9 тактов!

Не знаю, как по-вашему, для меня один порядок - десять раз. Сэм-восэм или там 12-20 - тоже подходят, я не зануда.


Бред ?



Не вдаваясь: тогда округление логично добавить ?

Куда?

Нет, народ. Это все измерение пиписек. При таком подходе, конечно, AVR не хватит. Надо подходить к решению (к оптимизации решения) задачи в комплексе. Если бы я банально собрал jpeglib, то на AVR оно еле-еле бы шевелилось.

Ну простой пример из моего кодера - в DCT, хоть оно и целочисленное, но удалось уменьшить разрядность умножения (точнее, количество операций mul) в связи с тем, что все коэффициенты, кроме одного не превышают 1, а тот, который превышает, тот так обрабатывается - b=a+(k-1)*a. А там этих умножений - как деревьев, которые все в гробах, - тьма...

И много других хитрых моментов есть.

Вообщем, пока тут всё голословные утверждения, хватит AVR или не хватит. И будут они голословными, пока нет хотя-бы наброска алгоритма.

так ежкин кот, сказал же, отличие по скорости между 8x операндами и 16x операндами в 2 раза.
До порядка далеко.


Такой же как и ставить DSP в выключатель.


Вроде mse говорил что щелкал FFT на m48 в real-time. Вот только сейчас не вспомню где искать. ;>

Ну мы, например, в аудио-тахометре (который измеряет частоту вращения по звуку) тоже не особо извращаемся, тоже FFT на m16. Раз в секудну обновляем показания. Клиенты вполне довольны

Весь вопрос, какого размера FFT нужен. И еще, не следует забывать, что FFT не самоцель. Например, в JPEG-кодере на обычных камнях DCT занимает примерно 50% и примерно 50% занимает квантизация и хаффман. А на BF - 25% DCT (конечно, многоствольные MAC-операции, все дела), остальное - 75%... Вот такая вот загогулина получается.

Еще раз повторюсь, алгоритм надо рассматривать в комплексе.