Как видно по дизасемблеру, умножение двух long(32 бита) занимает 4 такта.
Кроме того есть инструкиця множения с накоплением, которая позволяет за один такт перемножить два операнда и прибавить к некоему третьему.
М.б. в Вашем ARM'е умножение и занимает один такт (надо уточнить).
На самом деле это не слишком принципиально.
Очевидно, что если никто не заставит (в самый неподходящий момент) CPU "немножко подождать", то все он перемолотит. А вот если ему надо будет постоянно-время-от-времени приостанавливаться -- никто не знает. Кстати, обратите внимание на конфигурацию системы с SRAM из дата-шита. Если бы все было так просто, она не была бы актуальной.
Так вот в книге посвящённой ARM (ARM Development guide) есть отдельная глава по DSP, где говорится о том что процессоры с этими ядрами применяются в устройствах считывания CD и пр., где математика обсчитывается.
(1) в CD обсчитвается специфическая математика -- 2 следящих системы + Рид-Соломон+линейный код. И не факт, что этим эанимается отдельно взятый АРМ без специфической обвязки. А даже если и так -- это отнюдь не Фурье. У меня вот тоже АРМ есть в плеере, только называется он TMS320DM64xx (ARM9-200+DSP-ядро от TI, см., если интересно). Т.е. сам ARM занимается только чтением/записью, менюшками на экране, кнопками, USB и распознаванием форматов, а все кодеки живут в DSP-ядре.
(2) Ежели у Вас все под пальцами -- поробуйте изобразить чтение в реальном времени 16-битных чисел, фильтрацию + модель того, что должно стоять на выходе Фурье. Загрузите по максимому
всю потребную переферию. И конечно,
заложите механизм обнаружения потерь, т.е. факта пропуска отсчетов. Все, естественно, в той программной среде (if any), которая предполагается к использованию. Далее, навесте на все это программную болванку, слегка грузящую проц, например, разумно-периодическим сканированием памяти в объеме, потребном для фурье * 2. Пока это не заработает без пропуска отсчетов хотя бы с 2-кратным запасом по частоте дискретизации, дальше двигаться нет смысла. Когда получится -- дай Бог! -- дальше -- очень может быть, что Вам и программной точки поддержки компилятора хватит; а может быть, придется самым подробным образом изучать DSP-расширения (с реализацией на ASM) -- все эти тонкости реализации -- приятные хлопоты, после того, как динамика работы платформы сформирована. А код ARM'а компилируется классно, о да -- если убрать из примера 'volatile' -- он будет еще раза в 2 красивше.
(3) Вырожденные экспирименты с коротким кодом, "работающим сам на себя" ограниченно полезны, но дать представление о реальной производительности системы они не могут, на мой взгляд. Т.е. могут, но только в смысле
верхней оценки.