QUARK

QUARK is a simple dual-stack CPU instruction set architecture (ISA) that can be extended.
QUARK uses Head-and-tail instruction format, described in Hedi01.pdf

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

Однозначного ответа тут нет. Формат команды тесно связан с микроархитектурой процессора. Можно ведь такого накрутить, что схема станет медленнее просто из-за необходимости разобраться в сложной команде с разной ролью одних и тех же битов в разных случаях.

FORTH processor with Java compiler
MyForthProcessor (Download репозитория порядка 200Мб)

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

Eщё один Форт-процессор оригинального дизайна на Github.
N1 on Github
(N1_manual.pdf)

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

1. 16 бит, low-end. В современные low-end лезет и 32, и 64. Внутри полно команд для двойной длины. Отсюда вопрос - а зачем было сразу себя ограничивать?
2. Понятия "назначение", "целевые задачи" опять проигнорированы. Получилось упражнение по расстановке полей команды.
3. "Верификация еще не начиналась" То есть оно еще, возможно, и не работает?

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

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

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

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

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

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

А, были ли какие то замеры улучшения характеристик Форт ядер от версии к версии.

Примерно вот так. Размер в ресурсах ПЛИС зависит от параметризации.

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

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

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

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

В принципе мысль технически реализуема, но вопросы начнутся потом.

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

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

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

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

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

Спасибо за развёрнутый ответ.
Думаю да, если не попробовать такой вариант сделать или смоделировать, то нет полной ясности.
К, тому же, например у части контроллеров есть интерфейс к памяти расширения поддержанный аппаратно и он быстрее чем IO через порты.

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

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

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

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

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