Форт система с минимальным ядром

vpn289

Hishnik писал(а):

Именно!

Часто встречаю мнение (и согласен с ним), что проще научить специалиста-предметника немножко программировать, чем учить программиста предметной области. Программист же не может сначала писать бухгалтерский софт, потом - САПР для крупнотоннажных кораблей, а потом АРМ медицинской установки. У него банально не хватит знаний о том, что он пишет. Именно здесь и есть хорошая ниша для скриптовых языков, в том числе и Форта. Раз у человека голова не замусорена никаким конкретным языком, он примерно одинаково воспримет и С, и 1С, и Лисп, и Форт.

Ну это очевидно. Сам проходил такое. Чтобы что-то делать, нужно знать предмет.

Hishnik писал(а):

Отсюда, правда, следует, что и стандартные конструкции управления можно хотя бы предложить. Потому что из BRANCH MARK RESOLVE, конечно, выводится IF WHILE REPEAT LOOP, но не вполне очевидно и не за пять минут. А мы же не ставим задачу продемонстрировать свое превосходство? Лучше ведь, когда такой специалист начинает практически с ходу мигать светодиодами, принимать сигналы от датчиков, работать с периферией и т.д. Там он уже себе наработает шаблоны кода, которые ему понравятся, но выход на его профессиональную сферу стоит сделать максимально простым.

Я не предлагаю бросать в предметника голым ядром. Мне было интересно понять насколько форт-система может быть открытой. Оказалось весьма существенно. И переносимость исходных текстов тоже оказалась довольно высокой. То-есть объем переписываемого кода под другую платформу заметный, но не пугающий.

Hishnik писал(а):

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

Согласен.
Но Форт требует перестраивать мышление. Многих пугает еще то, что в Форте "ничего нет", ни структур, ни плавающих чисел и т.п.
На форте часто прикидываешь как что-то должно выглядеть в листинге, как пользоваться этим. А потом прорабатываешь детали, начиная с мелочей.
Например хочу:

Код:

STRUCT: mystruct
  QWORD elem1
  QWORD elem2
  DWORD elem3
  BYTE  elem4
;STRUCT

0d 1 0d 2 0d 3 0d 4 mystruct store

mystruct    elem4 get   elem2 get +     elem1 store

mystruct get  word_using_structure_data

И прорабатывая по частям получаю нужное мне. Ну какому сишнику придет в голову, что можно сперва придумать как должна выглядеть программа, а потом разбираться с тем, как это сделать?
Отличается Форт сильно подходом к решению задачи от других языков.

gudleifr

vpn289 писал(а):

Ну какому сишнику придет в голову, что можно сперва придумать как должна выглядеть программа, а потом разбираться с тем, как это сделать?
Отличается Форт сильно подходом к решению задачи от других языков.

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

chess

vpn289 писал(а):

Словарей в ядре два. FORTH32 и почти пустой ASSEMBLER.
IMMEDIATES создается гораздо позже, в расширении для автоматической компиляции.
Изначально ВСЕ слова только исполняются. Компиляция выполняется "ручками". Парой апостроф-запятая.

Ядро - это то, что написано на стороннем ассемблере. То, чего нельзя посмотреть простым редактором.

Понятно. Ну тогда IMMEDIATES выбросить не из ядра.

kzagradskiy

vpn289 писал(а):

Рабочее название openforth (sorry VoidVolker).
Ядро содержит 2 группы слов.
1) Обязательные, независмо от платформы
FORTH32 BADWORD EXIT Push Pop HERE INTERPRET interpret# PARSE ENCLOSE CONTEXT CURRENT @ !
CELL+ , ALIGN ' SFIND EXECUTE >IN N>LINK LATEST (WORD) (HEADER) HEADER 0xd 0x number
LINK UNLINK BADWORD-xt BUFFER

ASSEMBLER BADWORD EXIT opcode

2) Обязательные, зависящие от платформы
Для WIN32, WIN64, LINUX, Kolibry: OpenFile INCLUDE: rdfile CloseFile (LIB) (SetModule)
Для Baremetal: LOAD rdblock

Далее подгружается с помощью INCLUDE: или LOAD файл loads.f или block#1, в которых расписан дальнейший порядок загрузки с помощью INCLUDE: или LOAD соответственно.

Загрузка системы производится посредством интерпретации исходных текстов. То-есть, кроме ядра, вся остальная система наличествует в виде открытого исходного кода.

Загрузка производится этапно:
Сперва загружается встроенный ассемблер, точнее определяются мнемоники инструкций.
Затем загружаются низкоуровневые слова, определяются слова сперва для "ручной" высокоуровневой компиляции, а затем и автоматической компиляции.
Далее система расширяется в зависимости от платформы, доводится до состояния "работающая консоль".

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

Отличия от традиционных Форт-систем:
1) Нет BASE
2) Нет STATE
3) Нет флагов.
4) Числа не вводятся автоматически. Для ввода чисел используется слово 0x. В ядре сделан только ввод
16-тиричных чисел!
5) Изменена работа со словарями. Слово-словарь не включает сразу свой контекст, а лишь кладет его на стек. Его можно сделать контекстным или текущим так

Код:

vocabularyname CONTEXT ! vocabularyname CURRENT !

Отсутствует стек контекстов, вместо него введено понятие "сцепленных" списков.
6) Вместо NOTFOUND сделано похожее слово BADWORD - векторное слово, которому можно присвоить
любое нужное действие.

На данный момент равивается версия на ядре Win64

Исходники лежат на GitHub
https://github.com/vpn288/openforth

Новички на форуме часто заводят темы которые уже обсуждались. Прочитайте похожую тему [минимальный форт-транслятор] В ней так же упоминается eForth (максимально портируемый за счет минмального ядра в 30 слов).

KPG

kzagradskiy писал(а):

Новички на форуме часто заводят темы которые уже обсуждались. Прочитайте похожую тему

Можно предложить TC в первом сообщении указывать какие топики были прочтены к ознакомлению и какие выводы сделаны

а модераторам собирать похожие топики в одной форумной ветке обсуждения.

Victor__v

Хочешь написать форт?
Посмотри исходники доступных форт-систем для начала
Проведи компиляцию в голове и уж дальше тренируйся
Я тоже хочу форт написать и уже нашёл баг в форке и лаг в СПФ
Зачем придумывать свои баги?, если можно переделать уже работающее?
Да к тому же, помощь в любом случае понадобится.
P.S
В соответствующие темы уже отписался.

gudleifr

Victor__v писал(а):

Хочешь написать форт?
Посмотри исходники доступных форт-систем для начала

Достаточно Баранова&Ноздрунова. Читать чужие исходники, конечно, полезно, но на 90% это мусор, который никому не пригодится (к тому же большая часть копируется авторами друг у друга совершенно бездумно). За это время вы десяток своих FORTH-систем напишете.
Что касается каких-то трюков FORTH-программирования ядра, то тут гораздо важнее ваше знание языка/машины на/для которых Вы его пишете.

Hishnik

Victor__v писал(а):

Хочешь написать форт?
Посмотри исходники доступных форт-систем для начала
Проведи компиляцию в голове и уж дальше тренируйся

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

Victor__v

Или так.
Такие вещи написать с наскока можно, но всё ж лучше продумать.
Что входит, какие механизмы, и пр.
Сейчас как раз продумываю всё на тетрадке

Какие слова будут, их разделение по типам ( память, стек, модификация)
Идеи верхнего уровня. А нужно ли хеширование слов.статей? Часто ли будут навешиваться обработчики на слов?
И тому подобное

Hishnik

Victor__v писал(а):

А нужно ли хеширование слов.статей?

Ответ: если поиск в словаре занимает заметную долю в общем времени работы программы на Форте, будет полезным ускорение этого поиска. Для этого надо замерить это время. Пока я вижу загрузку форт-программ за доли секунды. Хэширование, соответственно, заберет время на реализацию и не даст никаких заметных преимуществ. А просто для красоты ничего нет смысла применять.

gudleifr

Victor__v писал(а):

Какие слова будут, их разделение по типам ( память, стек, модификация)

Их всего пять - ОК, СИМВОЛ, ВЫПОЛНИТЬ, КОМПИЛИРОВАТЬ, СЛЕДУЮЩИЙ.
http://www.gudleifr.h1.ru/cgi-bin/pilo.cgi?FL=../g9.txt&IS=%5C1.INTERPRETATOR%5C1.ZIKL%20UPRAWLENIA

Victor__v писал(а):

А нужно ли хеширование слов.статей?

Нет.

vpn289

chess писал(а):

Понятно. Ну тогда IMMEDIATES выбросить не из ядра.

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

vpn289

kzagradskiy писал(а):

Новички на форуме часто заводят темы которые уже обсуждались. Прочитайте похожую тему [минимальный форт-транслятор] В ней так же упоминается eForth (максимально портируемый за счет минмального ядра в 30 слов).

Собственно, эта тема и подвигнула меня на мысли. Потом появились еще мысли. А потом, чтобы проверить свое видение, пришлось погрузиться в писание. А теперь есть предмет для разговора, а не просто мысли.
eForth все равно немножко не то. Там сделан один очень интересный шаг в сторону разделения интерпретатора и компилятора. Но этого мне кажется недостаточно.

chess

vpn289 писал(а):

Не улавливаю Вашу мысль.

Мысль очень проста. Не нужно делать транслятор для того, чтобы он стал как можно проще, логичнее что-ли.
Нужно делать такой транслятор, чтобы программы было писать проще. Это две большие разницы.
1. Различные сущности для начала должны обозначаться-именоваться по-разному.
2. Ну и в программе должен быть виден контекст решаемых программой задач, а состояние, в котором
находится транслятор не должно быть видно. Реализация пункта 2 следует из реализации пункта 1.
Грубо говоря контекст решаемых задач управляет транслятором, а не программист.
Ваш случай. IMMEDIATES отдельный список. Потому, что имя слова исполняемого выглядит как имя слова компилируемого.
Поиском транслятор определит где какое. А если я захочу компилируемое слово исполнить? Почему один и тот же код нельзя
использовать и так и так? Кроме того глядя на имя слова давно написанной программы нельзя сказать это слово какое. Опять
влезать в состояние транслятора на момент создания слова - куда это слово поместили в IMMEDIATES или куда еще.
Если изначально закладываете в транслятор ущербные решения, то потом в ходе самораскрутки транслятора эти решения купировать будет труднее, чем на начальном этапе.

vpn289

chess писал(а):

Мысль очень проста. Не нужно делать транслятор для того, чтобы он стал как можно проще, логичнее что-ли.
Нужно делать такой транслятор, чтобы программы было писать проще. Это две большие разницы.

Ммм.. А что значит "проще писать"? Довольно эфемерная вещь, о которой говорить и говорить.

chess писал(а):

1. Различные сущности для начала должны обозначаться-именоваться по-разному.

Не вполне соглашусь. Возьмите слово set. Сколько сущностей оно обозначает? Как-то нас это не смущает.

chess писал(а):

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

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

chess писал(а):

Грубо говоря контекст решаемых задач управляет транслятором, а не программист.
Ваш случай. IMMEDIATES отдельный список. Потому, что имя слова исполняемого выглядит как имя слова компилируемого.
Поиском транслятор определит где какое. А если я захочу компилируемое слово исполнить?

Ну не совсем так. IMMEDIATES версии слов у меня записываются по-другому. IF для комплируемого слова, If для немедленного исполнения. Для исполнения компилируемого слова есть квадратные скобки. Всегда можно договориться как-то обозначать слова немедленного исполнения. Главное, чтобы было не громоздко и коряво. Да хотя бы брать имена в квадратные скобки. Этот вопрос, думаю, следует вынести на голосование общественности.

chess писал(а):

Почему один и тот же код нельзя
использовать и так и так?

Не понял, что имеется ввиду.

chess писал(а):

Кроме того глядя на имя слова давно написанной программы нельзя сказать это слово какое. Опять
влезать в состояние транслятора на момент создания слова - куда это слово поместили в IMMEDIATES или куда еще.

Как-то это вообще не беспокоит. Никогда дискомфорта не вызывало. Хотя Ваши опасения понятны. По моему, эта проблема нивелируется организацией текста программы.

chess писал(а):

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

У Вас есть предложения по решению мучающей Вас проблемы?

Форт система с минимальным ядром

Кто сейчас на конференции