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

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

Вот именно что забыл. Если Форт делается не для работы, а для удовлетворения чувства собственной значимости, эти переделки будут перманентными.

Если только он не "просто реализует" и/или "просто изучает реализации". А идет к этому снизу/сверху.
Это нам не грозит. Тут все начинают с "Вы изначально неправы".
Вы путаете достоинства FORTH с его недостатками. Это опять от того, что не хотите обсуждать "для чего", ограничившись манагерским (сами, ведь, просили) "для работы/для себя".

Не бывает так, это отговорки, чтобы не достигать результата. Изучение - это что? Сдать квалификационный экзамен? Потому что если просто что-то читать или писать какой-то код, то это только с большой натяжкой можно назвать изучением. Не встречали фразы "после окончания курса слушатель будет знать...", "после окончания курса слушатель будет уметь..."? Так вот что будет знать/уметь человек, который идет читать в Интернете про Форт?


Например, вот так?


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

Не бывает чего? "Просто изучения/реализации"? Пример "просто изучения" - это, например, тема коллеги Ethereal про "ошибки реализации". Пример "просто реализации" - это, многочисленные FORTH-системы, доведенные примерно до какого-либо стандарта.
Ну, как бы, тут уже не "изначально". Тут "опять".
А вот это, точно, увертки. Слово "работа" здесь избыточно. Без разницы, поставлена задача для бабла, или от избытка дури. Главное, чтобы решена была правильно.
Дык, по определению FORTH, он реализуется на любом процессоре. Другое дело, что реализовать процессор, на котором не идет ничего, кроме FORTH, проще любого другого. А, вот, процессор, который умеет что-то полезное (вспомните, например, машины клеточных автоматов), вполне может быть в остальном столь тупым, что программировать придется на FORTH...
Выиграть в быстродействии за счет тупизны? Вряд ли. Общая тормознутость языка сожрет всю выгоду от "стековых операций в один шаг".
Я про подобную нестыкуемость никогда не писал. Я, вообще, никогда не накладывал на A никаких ограничений.

Эта тема в заявленном виде тупиковая. Что будет в итоге? Большая козья морда всем авторам? Ощущение, что они идиоты? Это не может быть результатом изучения. Результат должен иметь метрические характеристики, а цель - проверяемой на достижение. Заявлять, что цель работы - "изучение" означает обеспечить себе беспроигрышный итог. Ну, я поизучал... стал умнее... как я это ощущаю. Бессмысленная своей непроверяемостью вещь. Это должно позволить другим авторам собственных реализаций делать меньше ошибок? Или должно позволить прикладным программистам быстро проверять используемые ими трансляторы на распространенные баги, и опять-таки делать меньше ошибок в своих программах?


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

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

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

Только я предлагаю считать эти темы тупиковыми не потому, что в них нет великой темы, а потому, что начато не с того конца. Может быть, там и есть рациональное зерно, но автор заведомо сам не настроен его искать.
Дык, единственный технический параметр FORTH: "тупость программиста, помноженная на сообразительность пользователя". Это единственное условие того, что что-то "удобно обеспечить именно на Форте". А ситуация "а Форта для такой платформы нет" невозможна в принципе: либо он пишется за две недели, либо он там и не особенно нужен (как в 'nix-ах).
Это не вывод, а ответ на вопрос, "Раз он ничего не может, может он, хотя бы, скоростной?". А вопрос построения супер-пупер стековой машины, это уже просто вопрос хорошего процессора, FORTH здесь только от "тупости программиста", ведь "алгоритмы на Си лягут на стековую машину практически так же".

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

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

Очередное обновление проекта GFOS

обновился проект GFOS
Modified Dec. 22, 2016

P.S. Forth Оси от mak4444

Сперва скачал файл по ссылке
http://fpauk.narod.ru/FCakeOS.tar.gz
Не нашел img что бы запустить в qemu.
Или его надо собирать

Чуть ниже
http://fpauk.narod.ru/BochsSPF-OFW.2.tar.gz
Прекрасно запустился. Похоже на msdos и даже волков командер есть.

Страшно грузит процессор, даже работая в холостом режиме.
Впрочем такая же фигня с поделиями ушлепков из майкрософт

A hobby implementation of a Forth interpreter and compiler, running directly on top of an x86 machine.
BYOK - a bare-metal x86 Forth OS

P.S. И ещё какой то раритет NAXOS