Еще один placeholder. Тут мы подумаем про одноядерные решения и способы затащить в них как можно больше полезного через шину команд.

"А стековые архитектуры процессоров - совсем умерли?"
http://www.rsdn.ru/Forum/message/3145957.flat.aspx

P.S. Обсуждение возможностей стековых архитектур.

заголовок темы по-моему не совпадает с содержимым первого поста.
что же имеется ввиду?

Исполнение команд Форта параллельно, но на одном ядре. Процессор в ПЛИС.

уф, слова все знакомые, а в цельное не складываются.
речь, вероятно, идет о выполненнии последовательности команд (часто встречающейся) как одной команды?

Ну вообще да. Просто "последовательно" и "параллельно" противоречат друг другу.

imho, скорее, не "часто встречающихся", а "независимых"

Например, команды DROP и CALL ADDR могут исполняться параллельно и независимо друг от друга.
и вовсе не обязательно в системе команд процессора иметь сдвоенную общую команду на все подобные случаи.
Достаточно устройству управления заглянуть вперед потока команд, найти подобные пары и согласованно раздать сигналы управления исполняющим устройствам так, чтобы исполнить эти команды одновременно.

А можно в словарной статье помечать можно ли это слово выполнять паралельно, но тут помоему специфика платформы должна быть, а иначе смысл в постоянной проверке пропадет.

Словарные статьи - это несколько иные "над"понятия в контексте данного раздела (Hardware),
да и пометки в статьях на все случаи жизни сделать невозможно.
А вот правила для команд процессора можно вшить в логику управления навсегда. И выполнять параллельно все, что не мешает друг другу.

Это, наверное, что-то типа Intel HyperThreading, когда ядро одно, но функциональных блоков несколько, и команды распихиваются между ними, по возможности загружая максимальное их кол-во. Так? Или, вообще, что-нибудь вроде VLIW. Но тока тут надо Форт-компилятор усложнять.
Вообщем, чисто железячные штуки. И очень интересные.

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

Надо только не забыть, что пока сие всего лишь теория, на практике никаких подобных параллельных исполнений (в моем варианте форт-процессора) нет, хотя, мысли были.

Сделать, naпример, проверку потока команд на наличие RET в конце (или середине) цепочки (загружаются ведь сразу 4 в 16-битном или 8 команд в 32-битном варианте процессора) и исполнять его совместно с предыдущей командой, если она не задевает стек возвратов.

По сути, в устройстве управления нужен дешифратор на две четверки бит с четкой логикой, как исполнять две команды параллельно, если такое возможно. Если нет, то команда исполняется только одна, а вторая в следующем такте сдвигается на первое место.

Ага, только тут есть грабли.
Желательно, по-моему, чтобы все команды выполнялись за одинаковое время, т.к. очень полезно бывает считать время выполнения, вносить задержки.
Кроме того, не известно на сколько велик от этого выигрыш, а проигрыш явно есть по сложности проца, а значит потребляемой мощности и т.п.

И что мешает посчитать соптимизированное время выполнения, если зависимость четкая и однозначная?

На счет усложнения - не думаю, что пара десятков LCELL сделает погоду на фоне нескольких сотен - тысячи, занимаемых процессором.

Ну, а выигрыш по времени в некоторых случаях может оказаться существенен. До полутора раз по прикидкам, если считать, что момент оптимизации возникает один раз из трех.
Снизить потребляемую мощность в этом случае проще с оптимизированной схемой, чем нет. Простым снижением тактовой частоты. Для КМОП потребляемая мощность пропорциональна частоте, т.е. при одной и той же средней скорости, частоту можно снизить до полутора раз, а заначит и мощность.

возможно, я излишне оптимистичен в оценках - они всего лишь умозрительные. Но даже ради такого игра стоит свеч.

Хорошо сказать, а вот как сделать?

А это уже вопрос времени и жизненной необходимости.
Будет и то, и другое - сделаем!