Одна из наиболее насущных проблем при программировании ядер SEAforth40 - относительно небольшой объем оперативной памяти, вследстии чего, приходится постоянно искать компромис между привычным стилем программирования на Форте - определение "мелких" слов и их последующий вызов и "ассемблерным" стилем - прямой код + макровставки. Иногда ценой "красивого" структурированного кода можно выиграть пару-тройку свободных слов.
Контроль размера кода лежит на программисте, т.к. компилятор о выходе за границу 64х слов скромно умалчивает ( по крайней мере та версия, что установлена у меня).
Есть и альтернативный выход - исполнение кода с одного (или нескольких) из портов, объем линейной программы для ядра при этом может дорасти слов до 250-ти--300, но ценой снижения скорости исполнения (где-то 1,5--2 раза)

для N=16 конвейер короткий получается. Т.е. у вас "степень" параллелизма 4. А влоб было 16. А эффективность быстрого преобразования для такой размерности выше ломового всего в три раза.

Т.е. 3*4<16

Все логично.

N увеличивайте. Или/и этапы распараллеливайте.

распараллеливание ручное в данном случае.

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

[quote="forther"]А быстрое преобразование Хартли будет?[/quote]
что-то черновые результаты по быстрому алгоритму Хартли не очень радуют, по крайней мере для выбранной на данный момент стратегии: задействовано всего 7 ядер, распараллеливание конвейерное по этапам, локализация вычислений в ядрах (одно или два ядра выполняют преобразования этапа - или расчёт бабочек, или перемежение данных, или генерацию индексов).
по времени получается пока от прихода сигнала до выдачи спектра Хартли приходит около 10000 тиков (ну или примерно 14 мкс). на последний этап уходит порядка 6000 тиков (при удачном раскладе можно попробовать уложиться в 2000-3000 тиков ), что и определит скорость преобразования в непрерывном режиме работы (для метода грубой силы получалось почти в два раза быстрее, да и алгоритмы работы ядер по-проще). :-)

И, как вы и сами наверно уже догадались, было бы ошибкой тащить это в цикл, чтоб поделить на 16.

[code]: d16/
$3fff0 # and a! +*
+* +* +*
a@ ;[/code]

хм..... не в пример проще :-)

почти

: d2/ 2/ 2* a! +*
a@ ;

[quote="forther"][quote="diver"]заменить деление сдвигом (но баловаться со сдвигами чисел двойной точности то ещё удовольствие)[/quote]

Показать "ответ" или сами попробуете? Есть (на мой взгляд) элегантный вариант d2/. Конечно, как задача для всех она не подходит, потому что завязана на специфику SEAforth. Но вы, если подумаете, то сможете найти это решение.[/quote]
примерно как-то так :-) :
[code]
: d2/ ( dh dl -- d2/h d2/l )
\ используем особенности реализации команды +*
a! dup push \ a=dl ; -- dh ; r: -- dh
dup xor \ -- 0 ; a=dl r: -- dh
pop \ -- 0 dh ; a=dl r: --
. +* \ -- 0 dh2/ ; a=мл.бит_dh_dl/2;
push \ -- 0 ; a=мл.бит_dh_dl/2; r: -- dh/2
drop pop a@ \ -- d2/h d2/l
;
[/code]

:-) побалуюсь ещё.

[quote="diver"]заменить деление сдвигом (но баловаться со сдвигами чисел двойной точности то ещё удовольствие)[/quote]

Показать "ответ" или сами попробуете? Есть (на мой взгляд) элегантный вариант d2/. Конечно, как задача для всех она не подходит, потому что завязана на специфику SEAforth. Но вы, если подумаете, то сможете найти это решение.

[quote="forther"]А быстрое преобразование Хартли будет?[/quote]
Если в "бабочках" разберусь :-).

А быстрое преобразование Хартли будет?

mOleg, ссылки на источники завтра добавлю и на преобразования и на доки по процессору. С кпк это не очень удобно . :-)

[quote="forther"]Здорово! Большое спасибо. А без деления на константу нельзя было обойтись?[/quote]

В принципе можно попробовать, варианты могут быть следующие:
- учесть константу при задании таблиц cas(vt);
- работать с операндами такой длиры, чтобы результат произведения был не более 18-ти бит (в принципе для случая обработки сигналов с АЦП ситуация реальная);
- заменить деление сдвигом (но баловаться со сдвигами чисел двойной точности то ещё удовольствие);
- дописать умножение 2-словного числа на 1-словное.

Если рассматривать в плане выигрыша по времени - реальнее вариант второй. Остальные дадут порядка сотни тактов.

Здорово! Большое спасибо. А без деления на константу нельзя было обойтись?