chess
К моему сожалению, опять ни буквы не понял.

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

Видимо я плохой рассказчик, хотя честно стараюсь объяснить.

Я вот сколько смотрю на это все, столько и думаю, что несоизмеримость затрат и результата будет уже на самом первом уровне

Даже на простой программе (как то решали задачу на форуме о подсчете 1-х битов в массиве) при реализации оптимального алгоритма подсчета Форт(СПФ) оказался в 4-раза(это с оптимизатором-то) медленнее, чем ассемблер.
Несоизмеримость затрат и результата у меня стояла только на 2-м месте. При таком соотношении (в 4-раза) еще не надо смотреть на затраты - надо смотреть на результат. Затраты даже очень большие - здесь еще оправданы.

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

Разве здесь что-то было о выправлении нерационального алгоритма? И что здесь мешает разумной алгоритмической коррекции программистом?

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

А как ты это определил?

Кстати: ~profit/misc/countBits-af.f (ну и, походу: ~profit/misc/countBits-bac4th.f).

А, собственно по теме-то я и забыл: ~profit/misc/chess-asm.f.

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

В топике по подсчету битов результаты были - на ассме - 94 мс, на форте - 360 мс

А это кому-то надо?

На ассемблере писать трудоемко и как следствие малопродуктивно.

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

Что следует понимать под продуктивностью? Количество выданных строчек кода? Оно на ассемблере будет не меньше. Функциональность кода? Да, ЯВУ для того и придуманы, чтобы было больше. Производительность программы? В ключевых местах - ассемблер дает гораздо больше свободы и возможностей грамотному программисту. Итого - если уж брать ассемблер, то именно для того, чтобы грамотный программист имел возможность проставить "вручную" (а на деле - в виде удобных мнемоник) желаемую последовательность команд и интегрировать этот кусок кода в общий проект. Остальное - из серии "а я вот еще и так могу".

Для этого отладчик надо нормальный.

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

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

Подсчет числа бит в регистре я написал гораздо компактнее, быстрее по времени и производительнее по результату, чем варианты на Форте. А вот общая организация программы, интерфейс (в том числе завязанный на системные вызовы), разнообразные проверки и реакция на ошибки - это действительно проще на ЯВУ, поскольку именно эта часть достаточно стандартна и обычно уточняется в процессе работы с продуктом.

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

Это все верно, но без эффективного оптимизатора Форт просто не имеет реальных шансов для развития на PC.