Во, относительно свежее (2025 год): https://theultimatebenchmark.org/
Там штук 5 простеньких тестов на Форте плюс таблица с результатами для разных Фортов/процессоров, натравлю, пожалуй, какой-нибудь свой процессор на эти тесты.

Кстати, в природе есть готовый Coremark на Форте.

В этом в целом смысл программно-аппаратной системы. Как только появляется что-то простое и многотактовое (в смысле итераций), организуется аппаратный блок, потому что иначе начнется заведомо проигрышная попытка как-то ускорить Форт. Заполнение памяти из внешнего источника может идти просто каждым тактом, по второму порту BRAM. Например, с АЦП идет поток данных, тогда АЦП на своей частоте туда пишет, а процессор по второму порту читает (писать ему, собственно, и не надо). Или видеоконтроллер - тут наоборот, процессор пишет, а контроллер постоянно читает. Для видеоконтроллера как раз можно добавлять вывод линий в аппаратном цикле, а не в цикле процессора, потому что рисование горизонтальной линии с 4 параметрами на стеке - это постоянные манипуляции, вывод в порт (и копирование стека, чтобы не терять параметры). Заведомо проигрышно же, нет смысла ввязываться в "оптимизацию Форта".

С одной стороны, получается постоянная правка "по месту". А с другой - ну и что? Зачем биться головой в стену, пытаясь сделать процессор на все случаи? Вот есть освоенная и рабочая методика проектирования связок процессор+ускоритель, она уже в голове и готова к применению. Запросы "сделайте нам для всех, чтобы скачать и сразу все работало" - это для ситуации, когда нет времени и ресурсов на самостоятельную разработку. Например, если нужен беспроводной интерфейс, не делать же BlueTooth самому, если это не определяющий компонент изделия? Поэтому когда в системе процессор - это "просто процессор", его удобнее скачать откуда-нибудь вместе с комплектом средств для программирования. А если изделие само по себе строится вокруг эффективной связки цифровой схемы и софта, тут уже надо погружаться и тюнинговать, не ограничиваясь шаблонами "как оно у всех сделано". В ПЛИС-то нет никаких проблем подключить несколько областей памяти, и даже несколько адресных пространств. Можно и периферию отображать на регистры ядра процессора (если вокруг этой периферии все и вертится).

Что-то прям загорелся идеей сделать акселератор для работы с памятью, но повесить его на основной порт BRAM в промежутках между командами @/! (там времени вагон), а второй порт оставить в резерве для второго параллельного ядра. Вроде не сильно сложно должно получиться: если команда @/!, то за шины данных/адреса и сигнал write enable отвечает процессор, а в противном случае процессор от шин отдыхает, а там хозяйничает акселератор. Неочевидное преимущество такого подхода в том, что можем писать/читать/сравнивать данные из разных частей адресного пространства, а не только из основной RAM.

Тесты прогнал, результаты забавные. Надо только к общему знаменателю привести, чтобы было удобнее сравнивать: либо в итерациях на мегагерц, либо в тактах на итерацию. Там, кстати, и по прошлым сезонам какие-то результаты есть, но самих тестов в виде исходников нет, а так и их можно было бы прогнать.Не прогонял только тест stacks, т.к. у меня стек возвратов исключительно для call/ret и иногда для циклов, а всякие r@/>r/r> без надобности. И цикл begin-until почему-то не люблю (и не делаю) из-за необходимости "инвертировать" в уме условие, поэтому вместо него в теле всех тестов do-loop.

В тактах на итерацию:В основном некая серая масса в плане производительности (оставил лишь те, что получше) и особняком ARM и Celeron в двух нижних строчках в связке с gforth. А из моих лучший 3-битный, самый ходовой 4-битный и единственный 6-битный. В 3-битном нет умножения/деления/call/ret (да там вообще почти ничего нет ), поэтому результаты arith и nest где-то на уровне серой массы, но, на удивление, по всем прочим тестам ноздря в ноздрю с Celeron'ом. В 4-битном нет деления, поэтому на arith все еще уступает ARM и Celeron, но теперь на всех прочих тестах уверенно обходит Celeron, а на некоторых даже ARM. А в 6-битном есть 16-тактное аппаратное деление, аппаратные однотактные циклы while-repeat и do-loop, так что он даже ARM уделывает одной левой. Более того, даже в 4-битный также можно впихнуть однотактные циклы и деление. Осталось понять, почему арифметика на пару тактов медленнее, чем в ARM.
Но выводы какие-то делать нет смысла. Единственное, что точно понятно, что если процессор хотя бы отдаленно forth-friendly, то Форт на него ложится намного лучше, чем на процессор общего назначения.

Тут, наверное, стоит сначала решить: нужно ли паралельное выполнение копирования блоков памяти. Зачастую, давая команду копирования, мы ожидаем результат сразу после команды.

Вообще предполагается некий аналог DMA, который позволит применительно к разным областям памяти однократно/постоянно копировать/читать/сравнивать/заливать каким-то значением и т.д. В т.ч. при желании сможет быть использован в качестве strcpy/strcmp/memcpy и т.д. Или, например, для заливки изображений в видеоадаптер.

Просто для иллюстрации: на процессоре f44 одна итерация бенча Dhrystone занимает 5455 тактов. В теле теста всегда выполняется как минимум по 1шт. strcpy() и memcpy(). Или больше, не вникал особо.
Так вот 20000 итераций strcpy(Str_2_loc,"DHRYSTONE PROGRAM, 2'ND STRING") выполняются за 977мс, а такое же количество присваиваний структур (memcpy) длиной 35 слов за 1232мс. В тактах получается 977 и 1232 такта на итерацию (по формуле время*частота/количество итераций) или 32 и 35 тактов на элемент. Т.е. только эти 2 операции отъедают 40% от всех 5455 тактов. А если такие операцию поручить акселератору, он отстреляется за 30 с хвостиком тактов. Ну или за 60, надо ж читать/писать. Пусть даже еще больше, если учитывать подготовительные операции по настройке регистров. Но в любом случае тут ничтожное количество тактов в сравнении с поэлементным ручным копированием. И нам останется лишь ждать в коротком цикле и опрашивать статус текущей операции, тактов на 6 тело такого цикла получится. Да и не всегда требуется ждать окончания операции, иногда получится обойтись и без опроса регистра статуса.

Вот! Пошло дело! Это как раз из серии качественных изменений в архитектуре, когда делаются не аккуратные вылазки из окрестностей известных шаблонов, а свободное мышление в рамках сформулированной задачи. Обычно так и бывает - с точки зрения схемотехники, можно конструкцию упаковать настолько плотно, чтобы каждым тактом происходило что-то полезное. Но с точки зрения логики и процесса разработки - для сложного проекта это нереально, невозможно все сразу вместить в голову и делать финальную версию системы, у которой ни одного такта не пропадает. Поэтому то, что надо менять, отдаем процессору, и постоянно "вытесняем" в аппаратуру проработанные и понятные фрагменты. И Форт тут очень к месту, потому что процессор со своей программой становится такой специальной вещью под названием "заткни временные дыры и не мешай".

Накидал в максимально простом варианте, пока чисто проверить концепцию. В адресном пространстве процессора 2 регистра, в которых хранятся адреса источника и приемника. DMA, когда шина свободна, постоянно копирует из источника в приемник.
В тесте натравливаем источник на переменную a, а приемник в цикле попеременно на переменные b и c. Инкрементируем a, а DMA мгновенно (по меркам процессора) пересылает новое значение в b либо c.В терминале такое:Сделаю, пожалуй, на этой базе memcpy и strcpy. Ну и, наверное, strcmp. Проблем не должно быть.

Немного copy/paste, тяп-ляп и готово.Аппаратный цикл со счетчиком и деление вместо rshift. В таком варианте разрывает Celeron на куски на всех тестах, да и ARM местами тоже, уступая ему немного лишь на тестах arith и logic, но тут как раз понятно: в системе команд мало места, поэтому сложения/умножения приходится делать через умножение с накоплением, а всю логику через nand. И процессору с 6-битными командами теперь не так заметно уступает. Вообще достаточно пластичная конструкция получается...
Система команд такая:

Кстати, добил указатели на функции в трансляторе Си-в-Форт, но Coremark все равно пока не будет работать, т.к. там, оказывается, еще и 32-битная арифметика нужна, а процессор 16-битный. Где-то у меня в загашнике есть Coremark на Форте, выложу, как найду.

Берем самый слабый процессор, прикручиваем к нему strcpy/memcpy через DMA, в результате 16384 итераций Dhrystone на частоте 20МГц теперь выполняется не за 6.266 секунд, а за 4.558 (если честно ждать окончание копирования после каждой операции) или даже 4.416 (если не ждать после memcpy, т.к. тут точно успевает, а после strcpy добавить немного ручных nop, там буквально пару символов не успевает скопироваться в том месте, где два strcpy в коде идут подряд, в теории такую добавку мог бы делать компилятор). Если в тактах на итерацию, то вместо 7649 становится 5471 или даже 5391 тактов. Т.е. производительность вырастает примерно на 40%, а число тактов на итерацию уменьшается на 2 с лишним тысячи. И хотя тут сложение вместо умножения или умножения с накоплением, 2/ вместо rshift или деления, а литералы набиваются 2-битными порциями, а не 4-битными, процессор, тем не менее, почти догоняет самые быстрые 4-битные процессоры из числа тех, что без поддержки аппаратных циклов. И немудрено, ведь копирование через DMA ест 2 такта на символ, а программное все 30-40, и даже если цикл развернуть, выйдет примерно с десяток-другой тактов. При этом strcmp все еще не через DMA, а программный. Пока обошелся тремя регистрами: адреса источника и приемника, а также счетчик. Если счетчик равен 0, то strcpy, иначе - memcpy. Не могу сообразить, как бы сюда поэлегантнее strcmp прикрутить.

upd. Ну и strcmp набросал на скорую руку. В итоге было/стало:Стало быстрее на 57%, а число тактов на итерацию уменьшилось с 7584 до 4844. И теперь этот совсем слабый и больной процессор обходит любой из тех, в которых нет аппаратной поддержки циклов, и даже большинство из тех, что с циклами. И это с честным ожиданием после каждой из операций strcpy/memcpy/strcmp, хотя некоторые опросы статуса можно безболезненно убрать, тогда за 60% будет прирост скорости. К остальным процессорам тоже прикручу DMA при случае, но сначала потренируюсь и доведу до ума на этом образце. Пока реализовано на тех же трех регистрах, для выполнения операции strcmp в счетчик надо записать отрицательное число, причем такое, которое не может получиться при посимвольном вычитании двух строк, например, 0x8000. Оно будет висеть в регистре статуса до первого несовпадения или до конца строки.

Вообще в данном конкретном тесте модуль DMA хоть и занимает шины попеременно с процессором, но такой режим работы сложно назвать параллельным, т.к. мы запускаем операцию strcpy/memcpy/strcmp, но продолжаем выполнение программы лишь дождавшись окончания этой операции. Хотя можно придумать много сценариев, когда даже такой примитивный DMA будет работать параллельно с процессором, сравнивая/копируя строки/блоки памяти, пока процессор занят другими более важными делами.

Надо будет еще оформить режимы работы DMA, когда забираем данные из одного и того же регистра периферии и раскладываем по разным ячейкам в памяти, либо наоборот пересылаем блок памяти посимвольно в один и тот же регистр периферии. Другими словами, когда размеры блоков памяти источника/приемника произвольные и могут различаться. Может паузу настраиваемую какую-то надо будет придумать, чтобы читать/писать периферийный регистр раз в несколько тактов, чтобы периферия не захлебывалась. И еще надо будет организовать возможность постоянной пересылки данных через DMA, а не только однократной, как сейчас. Заливка, поиск символа или подстроки и т.д., может еще что-то придумается по ходу пьесы.

еще upd.
Не удержался Для самого быстрого из 4-битных без/с DMA:Процессор с такой системой команд:Ускорилось на 56%, а в тактах на итерацию экономия почти полторы тысячи (4152 vs 2668). Для сравнения у 6-битного сейчас в районе 0.25 DMIPS/MHz, но там пока нет DMA

Dhrystone и Coremark на Форте:
http://totalvacuum.ru/BENCH/dhry.f
http://totalvacuum.ru/BENCH/coremark.zip

С Dhrystone сразу вопрос пересылки память-память.



Этот вариант LOOP сделает запись memdata в [I] и инкремент числа на стеке, а в мануле оно сразу идет на чтение памяти. Надо будет попробовать, уж очень интересно выглядит "программный DMA" на частоте 80 МГц...

Правильно ли понимаю, что тут будет такт на символ? У меня через DMA в идеальном случае лишь два такта на символ выходит плюс некоторое количество тактов вначале на инициализацию. А все потому, что пожадничал и оставил в резерве на будущее второй порт BRAM. Но даже в таком варианте ускорение очень заметное, впрочем, это актуально лишь для задач, активно использующих строки или memcpy.
Для коллекции 3 и 6-битный процессор без/с DMA:Такты на итерацию прилично экономятся: c 16578 уменьшается до 10796 в 3-битном и с 2106 до 1444 в 6-битном.
И только самый первый из 3-битных даже с таким ускорителем совсем безнадежен:
Тут аж 30 тыс. тактов экономия, но это капля в море на общем фоне в 600 тыс тактов на итерацию

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