[quote="KPG"] Может в этом варианте будет эффективнее сразу переложить выполнение части кусков кода программы, например, при возникновении прерываний на дополнительный контроллер.[/quote]
В самую точку! Это одна из объективных и существенных проблем сегодня. Для программиста вообще очень неудобно, что в критическом куске кода может внезапно возникнуть прерывание. Запретить - может возникнуть проблема с периферией, которую не обработают. А уж понятие "шторм прерываний" попросту показывает, что проблема получила собственное название.

Добавление независимых процессоров для работы с такими критичными кусками кода, или же просто для облегчения работы программиста - вполне перспективное направление. Если работа с собственным процессором не воспринимается как что-то запредельно сложное, жизнь внезапно облегчается. Программисту не нужно думать, хватит ли ему производительности. Ему не нужно думать, не нарушит ли добавляемый в основной цикл вызов функции нормальную работу предыдущих кусков проекта. Ему не нужно думать, что делать, когда прерывания перекрываются (а также как это проверить и хотя бы воспроизвести для тестирования). Вобщем, сплошные плюсы :) Из минусов цена.... но это цена одного компонента, и важно это будет разве что для пресловутого массового производства, до которого еще нужно добраться. А на сегодня +10-20 $ к спецификации далеко не всегда непреодолимая проблема. Тем более если это ускоряет выпуск нормально работающего изделия.

Кстати, kf732 был разработан именно с целью влезть в ПЛИС подешевле. Там-то как раз была серия.

[quote="Hishnik"]В принципе мысль технически реализуема, но вопросы начнутся потом..[/quote]
Спасибо за развёрнутый ответ.
Думаю да, если не попробовать такой вариант сделать или смоделировать, то нет полной ясности.
К, тому же, например у части контроллеров есть интерфейс к памяти расширения поддержанный аппаратно и он быстрее чем IO через порты.

P.S. Может в этом варианте будет эффективнее сразу переложить выполнение части кусков кода программы, например, при возникновении прерываний на дополнительный контроллер.

Кстати, интересно, что на AVR в ассемблере есть реализованные проекты микропроцессора 6502. :)

[quote="KPG"]Знаю, что, например на микроконтроллере делали в одном проекте микросхему памяти,
но в подобном применении можно сделать FIFO/LIFO а также возможно и возможность выполнения стековой арифметики или сразу или по мере необходимости (как то, наверное, можно и этим управлять - как быстро нужен, если нужен результат стековой арифметики следующим тактом или позже) какой нибудь и AVR может для этого сгодится. (часть стэка разместить в регистрах микроконтроллера)[/quote]
В принципе мысль технически реализуема, но вопросы начнутся потом.

Сама по себе связка МК+ПЛИС очень хороша и жизнеспособна. Эти микросхемы друг друга хорошо дополняют, потому что в МК обычно больше периферии, ну и стартовать проще именно оттуда, а в ПЛИС реализовать как раз недостающее по цифровой части. Это обычно или параллельное DSP, или коммутатор цифровой периферии, или какая-то схема, которой нет в МК - вот как раз вариант со стеком. Связать можно довольно просто через GPIO у МК. Да, он получит стек данных и команды по вкусу.

Первое наблюдение будет состоять в том, что постоянный обмен со стеком через порты МК будет медленным. В ПЛИС-то он будет быстрым, а вот МК придется постоянно забрасывать числа на стек, инициировать команды и забирать данные. Да, оно будет выполнять стековые операции за один такт[b] внутри ПЛИС[/b], но вот сколько тактов понадобится на обмен? Второе - такое ускорение стека, возможно, будет и быстрее, чем эмуляция стека в МК. Но будет ли она быстрее, чем просто программа для МК, написанная с учетом его архитектуры? Это уже очень неоднозначный вопрос. Скорее всего, нет - код на Си/ассемблере будет быстрее, чем код на Форте в связке МК+ускоритель стека.

Для форт-процессоров в ПЛИС смысл в основном в том, что они имеют компактный код. С учетом дефицита памяти на кристалле ПЛИС (сколько бы ни было, всегда не хватает, потому что от большой ПЛИС хочется и решения более серьезных задач). Сравнение с "официальными" софт-процессорами, конечно же, проводилось. Для реальных проектов упрямство не прокатывает :) Но оказалось, что аналогичный по функциям код имеет размер в 2-3 раза больше, если создается с помощью gcc. Это еще данные для kf332, у которого команда 18-битная. А уж kf532 делает такие вещи, что страшно с ARM-подобными ядрами сравнивать.

Второй важный момент - тесное сопряжение с периферией. 1 0 OUTPORT на форт-процессоре - это 3 такта. Если литералы получаются больше, то больше. Но многие МК на такой обмен с устройствами на шине тратят гораздо больше. Плюс добавляются игры с кэшем (если есть), прерываниями и прочими радостями... и получается, что очень удобно работать с каким-то собственным ядром, которое занимается одним процессом в системе, а на другие процессы при необходимости ставятся другие ядра. К примеру, kf732 - это прямой ответ на такую потребность, у него 8 аппаратных потоков, запускаемых по очереди (в произвольном порядке).

Так что в целом, форт-процессоры - это не про "очень быстро". Это скорее "очень удобно по совокупности свойств и маршруту разработки".

Появилась такая мысль.

Знаю, что, например на микроконтроллере делали в одном проекте микросхему памяти,
но в подобном применении можно сделать FIFO/LIFO а также возможно и возможность выполнения стековой арифметики или сразу или по мере необходимости (как то, наверное, можно и этим управлять - как быстро нужен, если нужен результат стековой арифметики следующим тактом или позже) какой нибудь и AVR может для этого сгодится. (часть стэка разместить в регистрах микроконтроллера)

А, если вместо МК использовать FPGA для подобной идеи например в дополнении такой памяти к МК общего применеия
через управление по портам, то получится ли регистровый МК общего применения сделать более эффективным к выполнению
поддержки Форт кода?

P.S. Насколько жизнеспособна такая идея? (типа дополнительная микросхема к МК, как небольшой стековый "сопроцессор" управляемый из вне)
Выпускаются или выпускались, конечно, микросхемы памяти LIFO/FIFO https://www.digchip.com/datasheets/parts/datasheet/305/M66250P-pdf.php
(M66250P, M66252P может и ещё есть, но они только для организации стэковой памяти)

[quote="KPG"]А, были ли какие то замеры улучшения характеристик Форт ядер от версии к версии.
[/quote]
Примерно вот так. Размер в ресурсах ПЛИС зависит от параметризации.

[quote="Hishnik"]2012 года. Оно уже устарело окончательно, даже kf532 редко применяем.[/quote]
А, были ли какие то замеры улучшения характеристик Форт ядер от версии к версии.

2012 года. Оно уже устарело окончательно, даже kf532 редко применяем.

KF 332 - конфигурируемое процессорное ядро

https://msyst.ru/index.php/activities/forth/114-kf-3xx

P.S. Картинки на странице пропали. :)
и нет обновления новостей.

Проект для M02mini: Процессор языка Forth в FPGA
https://marsohod.org/projects/proekt-m02mini/410-forth-j1

Проект для M02mini: Простейший интерпретатор Forth в плате M02mini
https://marsohod.org/411-prostejshij-interpretator-forth-v-plate-m02mini

[quote="KPG"]Eщё один Форт-процессор оригинального дизайна на Github.[/quote]
1. 16 бит, low-end. В современные low-end лезет и 32, и 64. Внутри полно команд для двойной длины. Отсюда вопрос - а зачем было сразу себя ограничивать?
2. Понятия "назначение", "целевые задачи" опять проигнорированы. Получилось упражнение по расстановке полей команды.
3. "Верификация еще не начиналась" :) То есть оно еще, возможно, и не работает? :)

Eщё один Форт-процессор оригинального дизайна на Github.
[url=https://github.com/hotwolf/N1]N1 on Github[/url]
([url=https://github.com/hotwolf/N1/blob/master/doc/N1_manual.pdf]N1_manual.pdf[/url])

P.S. Нашёлся при поисковом запросе Forth Cpu.

Spartan-3A. Снят с производства. Ячейки другие, непрограммируемые ресурсы другие. Под современные FPGA надо корректировать.

FORTH processor with Java compiler
[url=https://github.com/freecores/myforthprocessor]MyForthProcessor[/url] (Download репозитория порядка 200Мб)

[quote="KPG"]Насколько формат подобной упаковки процессорных Форт команд позволяет проводить локальные действия по ускорению кода?[/quote]
Однозначного ответа тут нет. Формат команды тесно связан с микроархитектурой процессора. Можно ведь такого накрутить, что схема станет медленнее просто из-за необходимости разобраться в сложной команде с разной ролью одних и тех же битов в разных случаях.

[url=https://github.com/drom/quark]QUARK[/url]

QUARK is a simple dual-stack CPU instruction set architecture (ISA) that can be extended.
QUARK uses Head-and-tail instruction format, described in [url=http://www.cs.berkeley.edu/%7Ekrste/papers/hat-cases2001.pdf]Hedi01.pdf[/url]

Насколько формат подобной упаковки процессорных Форт команд позволяет проводить локальные действия по ускорению кода?