Ну, как бы это понятно, но вот
не за один и не за два, а хоть за десять шагов но по факту их осуществления! А тут можно спрогнозировать
но дело хозяйское
зачем тогда так красиво упорядочивать коммманды

Упорядочивание команд имеет целью увеличение предельной частоты работы процессора.
Оно попросту уменьшает количество уровней логики необходимых для дешифрации команд,
которое и есть главный тормозящий момент вместе с количеством уровней, необходимым для ALU.

Кроме того, ловить исключения надо все же именно по факту, а не по подозрению.

Да, но это имеет и другие позитивные моменты- отчего бы их не использовать.

Кром е того, никак не пойму, что я неясно выражаю - комманды с префиксами именно позволяют ловить исключение по факту, но ДО свершения факта, который неизбежен (значит, до краха системы-искажения состояния-данных) а не после сверщения - по обработке префикса видно - свершится переполнение или нет.

Дело в том, что пока префикс (да и любая другая команда) не загружен в регистр команд, о нем процессор не знает совершенно и ничего сделать не может. Когда же он уже загружен, тогда поздно трепыхаться. И остается только надеяться, что исключительная ситуация не возникнет, а вот, чтобы такого не возникло, проверка производиться должна на уровне стека - так, чтобы отлавливать состояния "на грани" - осталось 2 элемента запаса глубины - пора делать слив со дна в память. Добрался процесс почти до дна стека (еще 2 DROP-a и конец!) - пора делать подкачку из памяти. Но делать это не тогда, когда из очереди команд послышится "пожар! щас потонем!" или "наводнение! щас погорим!"

Для большинства случаев хватает и 16. Нечасто же используется рекурсия.

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

Ну, в 80386+ схожим образом организована виртуальная память. Если страница, к которой процессор собирается совершить обращение, помечена как отсутствующая в памяти, происходит вызов подпрограммы, которая должна подгрузить эту страницу с диска, после чего и происходит выполнение команды доступа к памяти. Механизм прозрачен для прикладной программы. Стоит ли так делать для стека - отдельный вопрос. Имхо, при отсутствии четкого требования иметь стек размером больше нескольких тысяч ячеек вся конструкция просто отъест место в ПЛИС и уменьшит частоту.

Не совсем так. Строго говоря, у 386+ в случае недозволенного обращения к памяти происходит исключение (не важно, это попытка запрещенной операции или же обращение к "несуществующей" странице), которое физически выглядит как немаскируемое прерывание, обрабатывается соответственно как правило ядром системы, ну или кодом в нулевом кольце.
Также возможен вариант что тег-описатель нужного адреса вообще не существует, аналогично при обращении к такому адресу происходит исключение и тд.
Плюс в новых процах x86 свойства тегов страниц расширены: это например запрет кеширования определенной страницы, запрет исполнения стека,

Вопрос целесообразности однозначно определяется приложением: если будет исполняться исключительно код произведенный по всем правилам производства надежного кода, то конечно никакой защиты не нужно и она только съест вентили, которые лучше применить более полезно

Поток команд обрабатывается непрерывно, и прервать исполнение загруженной очереди уже ничто не может. Прерывания обрабатываться будут (сейчас этого еще нет!) в момент исполнения команды NOP.

Не сказано, сколько времени занимает умножение! Если его добавление занижает пред.частоту, лучше уж сделать *+ который хоть позволит делать быстрые небольшие умножения. Или генерить *+ взамен "отключаемого" MUL.
По определению MOVE ясно, что перекрывающиеся блоки будут копироваться неправильно.
А вместо MOVE красивше было бы примитивы типа @++ ( addr -- data addr+1) и !++ ( data addr -- addr+1) и к ним быстрый цикл типа чак-муровского unext.
Тогда можно определить всякие MOVE и FILL через них -- со сносным быстродействием.
Ну а делить в Эквиноксе только итеративным вычитанием? Ну, для отдельных константных делителей можно использовать MUL...

WingLion, симулятор будет?

умножение однотактовое, и частота при его подключении снижается - это видно
из таблицы http://winglion.ru/equinox/#4



а хитрые примитивы, скорее получатся не из выкидывания MOVE (оно там слишком нужно!) а через выкидывание дополнительных @-ret и !-ret, которые планируется совместить с @ и !
и пару освободившихся кодов можно будет пустить в дело



Делить пока только программно или умножением на обратную величину, если она известна.
Можно, конечно, и железное деление сделать, но оно все равно будет многотактовым.

А можно правый сдвиг добавить, зачем сразу желесное

сразу железное - проще. Потому что железное деление не на столько много места в ПЛИС занимает.
Всего-то 4*WIDTH ячеек, т.е. всего 64 ячейки для 16разрядного процессора. Что при объемах ПЛИС в десятки тысяч ячеек - совсем мизер.

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