[quote="вопрос"]Цитата:
любой неигрушечный компилятор Си эту структуру соптимизирует в jump table если позволяет платформа

Что по идее представляет собой оптимальную (по теории) реализацию такого алгоритма[/quote]

Ну и что из этого?
Мы получим тот же шитый код( косвенный ) с уменьшенным кол-вом слов 8( Дальше, для слов, которые не влазят в этот список из 256 слов нужно делать отдельный вызов ( вот тут и начинаются тормоза++ ), а выигрыш в обьеме сразу начинает сьедаться, к тому же адреса переходов и данный в такой системе не выравниваются в отличие от классического шитого кода, и получаются дополнительные тормоза...

[quote="in4"]По итогам обсуждения на irc #forth стало ясно, что принципиальной необходимости в наличии этого слова нет. [/quote]

Странно 8( Я часто пользуюсь им. Не то, чтобы не смог бы без него обойтись, но слово удобное. Уж легче обойтись без PREVIOUS.

[quote="in4"]Про "странные" - например в реализации словарей, а именно ALSO. Вот не понимаю, зачем добавлять в поиск последний словарь еще раз![/quote]
По итогам обсуждения на irc #forth стало ясно, что [b]принципиальной[/b] необходимости в наличии этого слова нет.
Были предложены способы обхода большинства несовместимостей. Ценой пересмотра кода.... :(
Исключение ALSO мизерно упрощает систему, вызывая несколько серьезных несовместимости в программах, оптимизировнных с учетом стандарта (использующих замену последнего словаря).

Я бы предложил его убрать в новом стандарте(вряд ли получится... :( - много кода, а вот если не тянуть совместииимость! ;) ) и (особенно!!) в других диалектах Форта, использующих идеи стандарта 94.

[quote]любой неигрушечный компилятор Си эту структуру соптимизирует в jump table если позволяет платформа[/quote]
Что по идее представляет собой оптимальную (по теории) реализацию такого алгоритма

[quote="oleg"]Я только что посмотрел в исходини vm.cpp и сразу же наткнулся на case структуру( уже не интересно смотреть дальше). При таких тормозах уж лучше использовать косвенный 16 битный шитый код( и то будет быстрее ).[/quote]

любой неигрушечный компилятор Си эту структуру соптимизирует в jump table если позволяет платформа

[quote="Гость"]in4 писал(а):

Про "странные" - например в реализации словарей, а именно ALSO. Вот не понимаю, зачем добавлять в поиск последний словарь еще раз! Чтоб поиск был подольше?


ALSO имеет смысл только если за ним идет имя словаря.
Ничего плохого в этом не вижу. Т.к. 2 словаря подряд, при этом,
существуют только при поиске имени словаря за ALSO.
ALSO играет роль открывающей скобки, а PREVIOUS закрывающей.[/quote]

Контекст - это тоже стек. Так что ALSO = DUP; PREVIOUS = DROP ;)
Два словаря оставлять на стеке контекста имеет смысл, когда работаешь в консоли с форт-системой. Это гарантирует, что если ты случайно забудешь написать перед именем словаря also то сможешь восстановить работоспособность системы. У меня обычно в том же Смал32 контекст при инициализации выглядит так:
ROOT FORTH FORTH - тогда при
VOCABULARY myVoc myVoc Definitions
Я автоматом получу ROOT FORTH myVoc -- это удобно.

Второй случай бывает вот такой примерно:
ROOT FORTH myVoc FORTH - это полезно, когда слова в моем словаре имеют те же имена, что и в главном словаре, например.

[quote="вопрос"]У меня упорное впечатление. что автор оказывает форт-сособществу ценную услугу.
Форт не имеет главного - удобной переносимости.
И вот ВМ, сделанная на СИ (правильно я понимаю?) даёт мгновенно форту одно из преимуществ СИ - переносимость, а ведь сколько не сотен а я полагаю десятков тысяч человеко-часов ушло у разработчиков си-компиляторов ... [/quote]

Реализаций форта на си даже больше чем на самом форте вместе с реализациями на ассемблерах вместе взятыми. Поэтому в этом плане актуальность невелика. Я только что посмотрел в исходини vm.cpp и сразу же наткнулся на case структуру( уже не интересно смотреть дальше). При таких тормозах уж лучше использовать косвенный 16 битный шитый код( и то будет быстрее ).

[quote="in4"]
Про "странные" - например в реализации словарей, а именно ALSO. Вот не понимаю, зачем добавлять в поиск последний словарь еще раз! Чтоб поиск был подольше? [/quote]

ALSO имеет смысл только если за ним идет имя словаря.
Ничего плохого в этом не вижу. Т.к. 2 словаря подряд, при этом,
существуют только при поиске имени словаря за ALSO.
ALSO играет роль открывающей скобки, а PREVIOUS закрывающей.

[quote="forth@km.ru"][quote]Форт не имеет главного - удобной переносимости.[/quote]

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

[quote]И вот ВМ, сделанная на СИ (правильно я понимаю?) даёт мгновенно форту одно из преимуществ СИ - переносимость, [/quote]

таких Фортов море

мне была нужна переносимость на уровне кода без перекомпиляции, [/quote]
АГА, всё же есть [b]разные переносимости [/b]...
и эта имеет свои преимущества [b][color=blue](?)[/color][/b]
байт-код, насколько я знаю, неплохо, его придумали умные люди и то, что он должен тормозить, это временный недостаток, сама идея важна ( IMHO )

[quote="forth@km.ru"]не умеешь читать Makefile ? там же 20 строк в простейшем синтаксисе[/quote]
Кстати, вот тут явно подразумевается, что надо еще и Си знать, чтобы твоей Форт-ВМ пользоваться. А это есть проблема "для чайников".

P.S. Я лично Makefile читать не умею... :( И Си не знаю.

сам я имплементировал интерпретатор, умеющий поддерживать как байт-код, так и шитый код

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

[quote="forth@km.ru"]проблема совершенно в другом -- базовый Форт очень низкоуровневый, а его расширение требует очень значительных вложений труда и времени

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

ну да, Форт можно расширить до Pythonа С++ Паскаля, только чем это отличается на написанию того же транслятора с нуля на любом другом языке ?

тут в форуме давали ссылки на реализации Си и Бейсика на Форте, да и просто какие-то библиотеки -- лезешь, загружаешь, ЫЫЫ! ведро исходника без какой-либо документации и комментариев, почему вообще тогда не отдавать в виде дампа откомпилированного машинного кода ? :) опять проще то же самое самому написать, чем ковыряться в чужих write only исходниках[/quote]
Немного аксиом:

Никто не говорил что следовать по Форт пути будет простое занятие:)
Расширений Форт языка предостаточно.
Разбираться с расширениями его, при желании, не составляет труда.
Расширять Форт удобнее, чем писать транслятор на классических языках.

P.S. Сложнее с привычками к синтаксису С подобных языков бороться:)
Против воли никто не заставляет использовать Форт язык.
Если, что не устраивает дописываешь сам или берешь уже кем то сделанное.

лучше SMAL32 форта не видел, жалко что проект сдох

Блин, да хотя бы подробную документацию к своим системам делать, да комментариев побольше (кашу маслом не испортишь) - уже дело бы пошло, и новичков привлекло. А так, когда в правило вошло делать абы как, "для себя же", "главное, что я понимаю", "этот кусок кода в пятьсот слов и так ясен", и т.п., никаких подвижек не предвидится.
Я себя еще помню как я полтора года назад впервые начал знакомиться с Фортом. :) Это сейчас я могу читать чужие исходники, не нуждаясь в подробных комментариях (кнопку F7 в Фаре скоро сотру до дыр :)) ). А тогда многие исходники из каталога devel\ казались мне китайской грамотой. :shuffle;

проблема совершенно в другом -- базовый Форт очень низкоуровневый, а его расширение требует очень значительных вложений труда и времени

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

ну да, Форт можно расширить до Pythonа С++ Паскаля, только чем это отличается на написанию того же транслятора с нуля на любом другом языке ?

тут в форуме давали ссылки на реализации Си и Бейсика на Форте, да и просто какие-то библиотеки -- лезешь, загружаешь, ЫЫЫ! ведро исходника без какой-либо документации и комментариев, почему вообще тогда не отдавать в виде дампа откомпилированного машинного кода ? :) опять проще то же самое самому написать, чем ковыряться в чужих write only исходниках