на 1-ку таки лишняя если, конечно, у вас под рукой есть быстрый процессор.
В случае создания проца, к примеру, в ПЛИС операция вполне имеет право на жизнь, но это все же другое дело.

Вы не там видите лишнее. Сдвиг не мешает делению, но делается быстрее.
Рассуждая по-вашему мы опять подойдем к надуманной проблеме минимального количества базовых операций. Если операция полезна и не мешает реализации остальных, то пусть будет.
На сложность принятия решений это не влияет.

более того, через него можно реализовать операцию деления, ну и что?


она вполне себе обоснованная (похоже не для вас).


ну, ваше дело.

В самом деле, пущай оптимизатор оптимизирует.
Помню, как я в одной системе вместо n*3 писал n+n+n, потому что оптимизатор схватывал только степени двойки.

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

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

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

Вот как-то пропустил момент, когда деление стало быстрой операцией

Вот что-то вы говорите не о том. Исправить комментарий к словам 2/ D2/ -
пара секунд, но проблема-то не только в этом.

В Forth-79 было симметричное деление.

В Forth-83 было деление с округлением по полу (по нижней границе).

В ANSI-Forth декларируется, что система может иметь либо то, либо другое
деление, но обязана обеспечить наличие примитивов SM/REM и FM/MOD,
позволяющих переопределить деление от одного типа к другому и обратно.
Вроде бы решение универсальное, но платой за это то, что в ANSI-Forth
выходит целая грядка разных примитивов деления.

Если мы сочиняем стандарт русского Форта, то мы должны выбрать какое
именно деление мы хотим из этих трех вариантов (или предложить свой
- четвертый вариант) и однозначно об этом в стандарте написать.

Ещё раз для тех, кто не понял.

Арифметический сдвиг вправо - это знаковое деление на два не вааще, а именно с округлением по нижней границе.

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

Да в той-же системе команд i80x86 :
SAR - знаковое деление на два с округлением по нижней границе
IDIV - знаковое симметричное деление
Так-что сделать SAR один раз - это не то, что делить посредством IDIV на два !
Поделите -3 на 2. Посредством SAR получится -2, а посредством IDIV выйдет -1.

2/ и 2 / - не обязательно одно и то-же !!!

И оптимизатор компилятора не может посредством телепатии получить информацию
какое именно деление вы имеете ввиду и понимаете ли вы вообще разницу между
разными видами деления. Так-что этот вопрос не может быть вынесен на уровень
оптимизатора.

Ну и грядка, ну и пусть, чем это плохо-то. Что-ли трудно запомнить и применять такой вариант, какой требуется?

Можно поменять название для 2/ на другое, чтобы не вводило в заблуждение, например на 1SAR
и использовать как деление на 2, только тогда, когда это корректно для результата.
Кстати, в форте много 'примитивов' еще, например, потому, что нет типов, и это нормально - голова от этого не распухает, а
гибкость оперирования с данными повышается.

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

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

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

Разговора об языке тут не было. Речь шла об оптимальном наборе команд платформ, ориентированных на определенные наборы задач. То есть вы высказались не по теме.
Что касается того о чем вы сказали есть и другой путь - расширямые языки(открытый транслятор). Я считаю этот путь более предпочтительным по простой причине - всего заранее не предусмотришь.

речь щла конечно, о трансляторах, реализующих языки, а что касается открытого транслятора, то это и есть 2 типа транслятора - открытый, где поиск потоянен и закрытый, где "всего не предусмотришь" - но

Есть у кого-нибудь соображения, какое деление полезней (удобней)?