Написание своего FORTH

Перейти вниз

Написание своего FORTH

Сообщение автор Gudleifr в Пт Июн 30, 2017 8:07 pm

Написание своего FORTH - это то, что с чего начинают все фортеры. Как это делать правильно?

ЧЕРНАЯ МАГИЯ
Прежде чем углублятся в ассемблерные дебри "самовоспроизведения" FORTH, рассмотрим этот "процесс" безотносительно конкретного языка программирования.
В старой книге "Этюды для программистов" Уэзерелла (сильно рекомендую) предложена задача: написать программу, печатающую самое себя. Как ее решить? Простейшее решение состоит в честном дублировании строк программы. Каждая строка встречается в программе дважды: один раз как оператор программы, второй - в виде строковой константы. Все, что делает программа - дважды пробегает массив этих строковых констант: первый раз печатает их как операторы, второй - с дополнительными кавычками - снова как константы. Что-то вроде:

НАПЕЧАТАТЬ ДВЕ ПОСЛЕДНИЕ СТРОКИ;
НАПЕЧАТАТЬ ДВЕ ПОСЛЕДНИЕ СТРОКИ В КАВЫЧКАХ;
"НАПЕЧАТАТЬ ДВЕ ПОСЛЕДНИЕ СТРОКИ;"
"НАПЕЧАТАТЬ ДВЕ ПОСЛЕДНИЕ СТРОКИ В КАВЫЧКАХ;"

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

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

Кажущийся очевидным "третий" способ: посмотреть, как написана программа и написать такую же, по сути, и не способ. Хотя мы постоянно применяем его, когда пишем свои программы, но заставить подобным способом воспроизвестись программу гораздо сложнее, а, в общем случае, просто невозможно.
Помните неудачу, постигшую героя романа К.Чапека "Р.У.Р."?
***

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

Это FORTH!
avatar
Gudleifr
Admin

Сообщения : 725
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Написание своего FORTH

Сообщение автор Gudleifr в Пт Июн 30, 2017 8:08 pm

ЧТО ТАКОЕ ЦЕЛЕВАЯ КОМПИЛЯЦИЯ?
Задача ставится так: у нас есть уже работающий FORTH и мы хотим одно из трех:

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

Изначально, когда FORTH имел вид кода, просто загружаемого в физическую память компьютера, целевая компиляция и сводилась к решению третьей подзадачи. Решалась она путем простого сброса оперативной памяти на диск "как есть". Чтобы потом так же тупо ее обратно загрузить. См. Мур.
***

Однако, современный FORTH не так уж и прост: он обычно разбит на части (даже если они упакованы в один файл), каждую из частей сохранять и воспроизводить имеет смысл способом, отличным от других. Например, львиную долю задач целевой компиляции сейчас можно решить сохранением/восстановлением только текущего пользовательского словаря. Да и современные операционные системы обычно не смотрят сквозь пальцы на программы, которые так нагло обращаются со своим образом в памяти.
avatar
Gudleifr
Admin

Сообщения : 725
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Написание своего FORTH

Сообщение автор Gudleifr в Пт Июн 30, 2017 8:10 pm

НУЛЕВАЯ ЦЕЛЕВАЯ КОМПИЛЯЦИЯ
Т.е. на входе - ничего, на выходе - наш первый FORTH. Я не буду здесь давать конкретные советы, только очерчу примерный размер бедствия.
Тут возможны две неприятные крайности: либо вы вынуждены работать на голом железе - даже без операционной системы, имея в распоряжении только программатор (этот случай описал Мур), либо, наоборот, ваша операционная система настолько умна, что практически не допускает написание какого-либо исполняемого кода. И я еще ныл, когда оказалось, что писать CGI-шники для своей странички могу только на Perl, PHP или C. А сейчас и Windows, в который раз, грозится ограничить пользовательское программирование написанием апплетов на языках все более странных виртуальных машин.
Вторая крайность для фортера гораздо страшнее, чем первая - отсутствует сам стимул что-либо писать. Если первые Palm-ы еще могли рассматриваться как маленькие персоналки, то сейчас все эти 'pаd-ы, скорее просто игрушки.
***

К счастью, обычно, ни той, ни другой крайности не наблюдается и, даже, если нам приходится прошивать голое железо, то саму прошивку мы можем подготовить во вполне комфортных условиях и затем достаточно просто загрузить.
***

Это порождает и важное отличие нашего FORTH-строительства от методики, предложенной Муром. Оно заключается в том, что нас лимитирует не стремление как можно быстрее перейти с ввода двоичных кодов к набиранию текста, сколько желание создать наиболее симпатичное FORTH-ядро.
***

По необходимости, мы вынужденны проводить первоначальное конструирование "третьим" способом, т.к. копировать и транслированием нам пока нечего. Мы вынуждены идти по аналогии - смотреть, как сделано у других и делать так же (или по-другому). Неправы те, кто говорит, что FORTH бывает только один. Если он и будет, в конце концов, работать по тому же стандарту ANSI-94, это ничего не говорит о том, что у него внутри. Более того, ваша конечная задача может быть сформуливована совсем не по-FORTH-овски, и FORTH-ядро будет в ней так глубоко зарыто, что никто и не догадается о его присутствии.
***

ЭТАП 0. Почему-то большинство фортописателей (особенно, пишущих на C) его тщательно замалчивают. Может, боятся потерять какое-то ноу-хау или, наоборот, не в силах постичь открывающиеся здесь перспективы, тщательно копируют единственное известное им решение?
Писать на этом этапе почти не придется, скорее, рисовать на бумажке. Именно здесь мы должны решить, как будут выглядеть все те структуры, которыми будет оперировать наш FORTH. Где и как будут размещаться стеки, как будет выглядеть словарная статья, что мы будем далее называть единичной ячейкой...
Большущий подводный камень, который нас здесь поджидает, состоит в том, что когда мы вдоволь наиграемся со своим FORTH, мы поймем, что надо было сделать все совсем не так. И косметическим ремонтом здесь не обойдешься, придется перепахивать все.
Конечно, если бы кто-то разбил FORTH на иерархию каких-то обособленных модулей: эти зависят только от стека, эти - только от словаря... то было бы проще. Но. Во-первых, FORTH легче написать, чем проанализировать. А, во-вторых, пресыщенному фортеру может показаться и этого мало, и он может замахнуться на нечто для других незыблемое. Какой тут может быть предварительный анализ?!
Впрочем, об одном нужно помнить всегда - не нужно закладывать ничего, что бы не диктовалось насущной практической потребностью.
Сам Мур, бодро изложив результаты этого этапа (и скромно умолчав о способе их получения) в третьей главе своей книги, все оставшиеся главы потратил на рассуждения, а не стоило ли все сделать по-другому?
Итак. После завершения этого этапа у нас будет бумажка "на которой написано, куда мы летим", исходный файл с парой макросов и десятком комментариев, и понимание того, чем и как мы этот файл будем компилировать, когда, наконец, напишем.
***

ЭТАП 1. Начинаем писать. Как известно, все слова FORTH делятся на два класса: слова, которые что-то делают (написанные на том языке, на котором мы пишем FORTH), назовем их кодовыми, и слова, составленные из других слов, назовем их шитыми. Можно выделить еще псевдо-слова: код, который выполняется, но в словарь не прописывается. Псевдо-слово, по-сути, необходимо только одно - начальной инициализации FORTH. Ну, если потребуется, еще парочка для обработки прерываний системы.
***

Задача этого этапа создать все кодовые слова, необходимые ядру FORTH. Если мы пишем свой FORTH в удобном редакторе и на удобном языке программирования, то очень легко впасть в ересь избыточности: "А вдруг пригодится?- Включаем".
Тут возможно два совсем уж извращенных подхода. Синдром высокого уровня. Очень часто C-фортостроители запрещают создание кодовых слов где-либо, кроме этого этапа. Мол, мы написали FORTH-виртальную машину и будьте добры программировать именно на ней. Понятно, что, при таком "подходе", либо мы полностью заранее покрываем все возможности процессорных команд (что явно невозможно), либо миримся с тем, что на что-то наш FORTH будет неспособным (обидно, даже, если мы не злобные хакеры).
Синдром структурности. Зачарованные словами "переносимость" и "машинно-независимость", многие фортостроители пытаются недопустить любое упоминание решений, принятых на этапе 0, выше этого этапа. Инкапсулировать их. Вводят специальные слова для размера ячейки, указателей на служебные области, преобразования типов... Результат: до 90% избыточности и до 50% потери производительности.
Так что, потихоньку вводим здесь кодовые слова, не забывая вставлять макросы, обозначающие сообветствующие словарные статьи. Хватимся (на этапе 2), что что-то забыли? Вернемся и вставим. Завершаем работу созданием стартового псевдослова. Все, уже можно компилировать!
***

А как делал Мур? Находясь в условиях жесткого форс-мажора, он, понятно, всеми правдами и неправдами пытался сократить объем этого этапа. Еще бы, ведь он набирал все коды на пульте! Сначала тумблера адреса ячейки (бит за битом), затем тумблера содержимого ячейки, потом кнопка записи, потом тоже для всех остальных ячеек. Поэтому он ограничился минимумом кодовых слов. Что надо для интерпретации ввода? Уметь считать строку, выделить из нее слово (WORD), поискать его в словаре (FIND) и проверить, евляется ли оно числом (NUMBER). Для занесения прочитанного в словарь нужно, для начала, только два слова: создать заголовок словарной статьи (ENTRY), и записать число, символ или код в словарь ("запятая"). Еще нужно псевдослово "Цикл Управления" - увязывающее все это вместе. И вот все это Мур написал в кодах. Зато, начиная с этого момента, он мог вводить слова и коды с терминала.
***

Хотя, я целиком и полностью за создание FORTH-системы на языке ассемблера, чтобы иметь возможность создавать кодовые слова средствами самого FORTH уже во время его работы, практическая потребность в этом существует далеко не всегда. Можно написать нечто подобное и на языке высокого уровня, и единственной расплатой за это будет необходимость сохранить компилятор "рядом" с FORTH-системой. И вызывать его каждый раз, когда захочется добавить новое кодовое слово.
Например, в DOS-версии FOBOS я правил исходный ассемблерный файл, наверное, чаще, чем пользовался встроенным FORTH-ассеммблером.
Т.е. дело в замкнутости и самодостаточности системы. Например, если я пишу FORTH-систему для карманного устройства, рассчитанного только на исполнение программ, а ассемблирование/компиляция программ происходит обычно "где-то там" - на "большой машине", то, разумеется, мне захочется иметь полный доступ к коду. Однако, железо и программная среда могут быть столь плохо документированы, что нужную для дела FORTH-систему в приемлимый срок можно создать только при помощи готовых высокоуровневых дурацких компиляторов.
Кроме того, писать FORTH на языке ассемблера/в кодах просто приятнее...
***

ЭТАП 2. Этап ввода шитых слов. Начиная с этого момента, мы думаем на FORTH, хотя и пишем в файл программы еще на исходном языке программирования (используя словарные макросы).
Мы даже можем позволить себе некоторые из основополагающих слов Мура определить как шитые. Например, ENTRY - оно очень удобно раскладывается на последовательность операций копирования строк и перерасчета адресов. Настолько, что даже само слово ENTRY теперь не используется. Многие любят порассуждать об оптимизации FIND (даже, сам Мур), но я еще не встречал случая, чтобы это решение окупилось. Тоже касается и слова WORD. А вот слово NUMBER очень удачно превращается в шитое с использованием аппарата конечных автоматов.
Ну ладно, а где заканчивается этот этап? Там же, где у Мура предыдущий - созданием шитого слова "Цикл Управления". Начиная с этого момента мы можем добавлять в нашу систему новые слова чисто в текстовом виде, понятно, с гораздо большим комфортом, чем Мур. Например, можем создать текстовый файл и копить в нем все необходимое.
Откомпилировав нашу программу в последний раз, мы можем забыть о нашем исходном языке программирования до тех пор, пока нам не захочется что-то кардинально поменять.
***

ЭТАПЫ 3-? Теперь нас более ничего не ограничивает и думаем, и пишем мы теперь полностью на FORTH, если, конечно, нам не захочется странного. В WIN-FOBOS, например могу выделить этапы:
3-й - встроенный ассемблер для создавания новых кодовых слов;
4-й - недостающие слова стандарта (в DOS-овской версии я почти весь FORTH-83 реализовал на этапе 2, а в Win-версии ввожу слова только по мере необходимости, например, слово для умножения мне до сих пор не понадобилось);
5-й - реализация проблемно-ориентированного языка.

Если интересно, можете посмотреть мой DOS-FOBOS (напомню, я просто переписывал на IBM PC систему Баранова и Ноздрунова) - RAR, 0.09Мб

Файлы:
G1.COM - исполняемый файл FORTH-системы
G1.DAT - файл с блоковой памятью
(Т.к. DOS давно не пользуюсь, но FOBOS время от времени запускал, то накопилось достаточное число заглушек, закрывающи удобные тогда, но не работающие сейчас "фичи": использование монохрома, DPMI, VESA...)
Дополнительные файлы:
G1.ASM - исходный текст G1.COM
G1 - make-файл для сборки G1.COM
G1.TXT - текстовое представление непустых блоков
FOBOS.BAT - командный файл-оболочка


Последний раз редактировалось: Gudleifr (Ср Дек 06, 2017 1:05 pm), всего редактировалось 1 раз(а)
avatar
Gudleifr
Admin

Сообщения : 725
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Написание своего FORTH

Сообщение автор Gudleifr в Пт Июн 30, 2017 8:10 pm

САМОРАЗВИТИЕ ЯЗЫКА БЕЗ ЦЕЛЕВОЙ КОМПИЛЯЦИИ
Такому ленивому программисту как я, показалось слишком затратным строить специальный целевой компилятор. Что можно, записывал в текстовом виде в подгружаемый файл. Иногда правил исходный ассемблерный файл и перекомпилировал его. Вполне хватало.
***

Такой подход мог бы даже примирить нас с C-фортерами (и другими высокоуровневыми), отрицающими создание кодовых слов пользователем. Но при одном условии - этим C-фортером должны быть Вы сами. Модифицировать чужой C-код? Это всегда кончается его полным переписыванием.
avatar
Gudleifr
Admin

Сообщения : 725
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Написание своего FORTH

Сообщение автор Gudleifr в Пт Июн 30, 2017 8:11 pm

ВАЖНОЕ ЗАМЕЧАНИЕ
Упоминавшееся выше писание "в кодах" не следует понимать слишком буквально. FORTH можно написать на любой машине! (Не путать с обычным для структурных фортеров "на любом языке"). Именно "на машине". Если угодно, "на машине, реализующей любой язык".
Что отличает язык от машины? Машина обязана иметь какую-то связь с внешней средой. А FORTH - это интерпретатор, который должен что-то интерпретировать, следовательно иметь возможность получать это "что-то" откуда-то извне.
Например, у на есть большой компьютер и есть боле простое (неудобное) программируемое устройство. Обычно, в таком случае программировать удобнее на большом, а на маленький сбрасывать готовый код. Имеет ли в таком случае смысл ставить FORTH-систему на маленький компьютер? Нет, нужна хорошая FORTH-система на большом компьютере (чтобы эффективно было писать) с удобным целевым компилятором (чтобы писать эффективный код для малыша). Тащить на устройство стек и шитый код при невозможности на нем программировать - это дурость.
Если же я хочу программировать на маленьком устройстве без "захода" на большой, то FORTH-система на нем будет полезна.
Не забываем, что Чарльз Мур считал "настоящим вводом" программы не ввод данных, но "допрограммирование" - ввод команд.
***

Уровень машины не обязательно должен меряться "по железу". Машина может быть достаточно высокоуровневой (виртуальной). Например, каким-либо офисным приложением, имеющим встроенный скриптовый язык.
Уровень создаваемой FORTH-системы определяется уровнем канала ввода FORTH-команд (ПОТОКА).
Например, желая сделать свои программы как можно более машинно-независимыми, я пришел к схеме perl+html. Что же мне теперь отказываться от FORTH? Зачем? Кодом будет perl. Канал - через html-form. Значение на стеке - файл (не имя/манипулятор,, а именно файл, целиком). Если понадобится залезть "глубже", дополню FORTH "водолазным оборудованием". Перестанет справляться - напишу новый FORTH. Тоже мне, проблема...
***

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

И не надо думать, что, начав с голого железа можно обойтись без вывешивания ПОТОКА. Обратите внимание на 6-й блок реализации Баранова и Ноздрунова - эти слова определяются до создания FORTH-системы.


Последний раз редактировалось: Gudleifr (Ср Дек 06, 2017 1:06 pm), всего редактировалось 2 раз(а)
avatar
Gudleifr
Admin

Сообщения : 725
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Написание своего FORTH

Сообщение автор Gudleifr в Пт Июн 30, 2017 8:12 pm

ПРИЛОЖЕНИЕ. ОТРЫВОК ИЗ КНИГИ
CHARLES H.MOORE PROGRAMMING A PROBLEM-ORIENTED-LANGUAGE

9. ЗАГРУЗКА
Иногда трудно оценить, как это все начинается. Мы молчаливо предположили, что ваш компьютер имеет компилятор и что вы используете его, чтобы скомпилировать вашу программу. Но как написан ваш компилятор? При помощи дугого компилятора на другом компьютере. Как биологии: живое происходит от живого. Все программы сделаны другими программами.

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

В Главе 1, я обсуждал грустное состояние качества программного обеспечения. Мы можем написать очень хорошую программу, а компилятор может ее сделать очень плохой. Начать нам придется именно с этого. Однако, дальнейшие компиляции лучше выполнять уже своими силами.

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

9.1. НАЧАЛО
Сначала вы будете должны узнать некоторые вещи: как включать и выключать компьютер (в нерабочее время), как работать с пультом и как избежать порчи данных на диске. Вам, вероятно, придется попытать операторов или инженеров, чтобы обнаружить такую информацию; очень редко ее оформляют письменно.

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

Теперь мы сделать что-то полезное. Мы собираемся начинать строить ваш словарь, даже при том, что вы не сможете его использовать. Вы должны выбрать ваш формат статьи; требуется переменная длина, но вы можете решать относительно размера слова и выравнивания. Первая статья - SAVE; она будет сохранять вашу программу на диске. При отсутствии цикла управления, вам придется запускать ее вручную, но она все равно сэкономит кучу работы. Вторая статья - LOAD; она загрузит вашу программу с диска. Если удастся привязать ее запуск к кнопке аппаратной загрузки, и вы сумеете поддержать необходимый формат, прекрасно. Иначе придется изготовить загрузочную перфокарту. Но всегда удобно иметь возможность рестартовать из ОЗУ.

Третья статья - DUMP; вывод ядра на принтер. Читать бумагу все-таки проще, чем лампочки на пульте. Это, вероятно, не тривиальная программа, но не должна занять более, чем дюжину инструкций. Вы можете отложить ее написание, но не надолго.

Итак, пара часов работы - если вы сначала прочли инструкцию - и вы имеет операционную систему (SAVE и LOAD) и отладочный пакет (DUMP). И вы уже много узнали о компьютере.

9.2. КОРНИ
Не волнуйтесь, я все проверил на себе. И даже дважды, правда, я не вел записей и теперь об этом жалею. Так что вы имеете простор для импровизации.

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

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

Никакая словарная статья не связана с вводом/выводом сообщений. Вы могли бы определить одну, но мы не будем нуждаться в ней. Вообще, мы будем строить статьи только, когда они станут необходимы. Мы можем всегда добавить любую статью, когда она понадобится.

Сделано много. Теперь установите стеки, подпрограмму поиска в словаре, статьи WORD и NUMBER. Будьте очень осторожны, делая это в первый раз; NUMBER можно немного упростить, перепишете его позже. Работа большая, даже если использовать тумблеры.

Теперь пишите цикл управления. Вы могли бы проверять стек, но переходы к процедуре ошибки пока остаются неразрешенными. Запустите. DUMP - все еще наша единственная программа вывода, но вы должны быть способны прочесть и выполнить слова DUMP, SAVE и LOAD.

Напишите статью для ENTRY, подпрограммы которая строит словарные статьи. Я не определил код, выполненный для WORD, NUMBER и ENTRY. Они - подпрограммы, и единственный случай, когда мы будем использовать их имена, это, когда компилируем код. Выполнить их, означает поставить инструкцию вызова. Этот код мы тоже не написали.

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

9.3. ВЕТВИ
Мы достигли поверхности. Невидимая работа сделана, и мы можем видеть что делаем. Сделать надо много и порядок неочевиден. Мы создали исходный язык, и мы должны быть способными изменить его и заново собирать без того, чтобы переделать все. Здесь мы вынуждены создать временный код, который станет устаревшим, но это будет сэкономит много усилий.

Сначала статьи READ и WRITE, чтобы обеспечить доступ к диску через единственный буфер. Теперь простые T и R, чтобы напечатать текст в блоке. Они скоро устареют, так что пишите их просто.

Теперь нужны READ и ;S глаголы для SCREEN-ов. Определите номер блока, и мы можем читать текст в том блоке.

Теперь мы пишем SCREEN-ы: новые определения, улучшенный компилятор, улучшенная работа с блоками, улучшенный редактор текста, и мы можем продолжать наше приложение. Пишем статью REMEMBER. Без нее приходилось переустанавливать словарь вручную.

Я уверен, что вы заметили трудность изменениея кода в корнях. Мощным инструментом будет способность перемещать словарь в памяти. Если корень не использует абсолютные адреса, определите статью SHIFT и используйте ее. Иначе минимизируйте число абсолютных адресов, и определите более сложный глагол SHIFT, который их перерасчитывает.

Будьте осторожны, делая SAVE вашей программы. Делайте, на всякий случай, копию вашего предыдущего сохранения, прежде чем сохраниться снова.
avatar
Gudleifr
Admin

Сообщения : 725
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Написание своего FORTH

Сообщение автор Gudleifr в Пт Июн 30, 2017 8:13 pm

ЦЕЛЕВАЯ КОМПИЛЯЦИЯ
Как все просто в теории! Решаем на FORTH задачу, т.е. создаем финальное слово, объединяющее в себе всю его функциональность (например, ДОКАЗАТЬ-БОЛЬШУЮ-ТЕОРЕМУ-ФЕРМА) и запускаем для него заботливо предложенное нам разработчиками слово ЦЕЛЕВАЯ-КОМПИЛЯЦИЯ.
Во-первых, это тот самый "третий" способ. Который доказуемо не может работать, за исключением ограниченного числа простых случаев. Например, существует много задач, которые не сводятся к одному слову, например, интерпретатор любого проблемно-ориентированного языка. Как наш "целевой компилятор" сможет догадаться можно ли ему выкинуть INTERPRET, и, соответственно, отказаться от хранения в словаре имен слов? И как он сам догадается, оставлять ли в целевом FORTH многозадачность или нужно собрать приложение только для одного пользователя? Как ни крути, одним целевым компилятором не обойдешься - нужно написать по штуке для каждого конкретного случая (типа задачи). Т.е. мы возвращаемся ко второму способу воспроизведения (трансляция с какого-то языка), где информация о сборке новой программы неявно хранится в структурах целевых компиляторов.
Во-вторых, даже, если мы хотим собрать в виде нового FORTH ровно то, что получили из старого на данный момент, то задача без привлечения дополнительной информации неразрешима. Даже, если "образ" можно "просто" загрузить в память, как на очень простых процессорных системах, проблемой может оказаться неразрешимой без информации о приведении ее в начальное состояние. А алгоритмы приведения вашего "образа" в состояние, пригодное для загрузки современными операционными системами, могут потребовать не только дополнительной информации о параметрах "образа", но какого-нибудь особо хитрого перерасчета адресов (что само по себе может оказаться невыполнимым, т.к. FORTH нисколько не заботится о том, как в словаре отличить адреса от чисел).
***

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

- записать слова этапа 1 становится возможным только после этапа 3 (когда будет готов встроенный ассемблер);
- записать результаты этапа 0 просто невозможно (а как мы только что видели, для целевой компиляции она очень важна);
- единственно, на что годен этот слепок, это при помощи нашего FORTH, перезаписать свой собственный словарь на точно такой же.

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

Возникает вопрос. Не проще ли работать не с "образами" в памяти, а с исходными файлами? Что мы знаем?
- никаких средств для формализации действий на этапе 0 нет, хотя, целевая компиляция и ставит обычно своей целью замену одних решений этого этапа на другие;
- если результат целевой компиляции должен выполняться на той же машине, кодовые слова можно просто скопировать (если на другой машине, то наш "генотип" ничем не поможет, т.к. встроенный ассемблер "генотипа" не будет соответствовать нашему);
- если кодовые и основные шитые слова нам удалость привести в божеский вид, то какая разница, скормим мы их целевому компилятору или тому компилятору, которым мы компилировали изначально?
- отсюда вывод: нужен не целевой компилятор, как часть FORTH, а обычный компилятор (может, написанный на FORTH), который будет обладать в гораздо большей степени свойствами обычного компилятора, чем какого-то загадочного "целевого", переводящего самого в себя и вытаскивающего самого себя за волосы. И не забываем: при изменении посылок этапа 0, этот компилятор придется скорее всего переписывать. Почему я не переписываю каждый раз ассемблер, которым компилирую новые версии FOBOS? Во-первых, я перешел с DOS-овского на Win-овый (а под Linux или Palm OS пришлось бы брать другой ассемблер). Во-вторых, потому, что ассемблер учитывает только свойства процессора и операционной системы, а то, что мы обычно пишем на FORTH, еще ограничивается нашими FORTH-установками.
- проблема "целевой компиляции" слов, введенных на этапах 3 и больше, яйца выеденного не стоит, т.к. правка текстовых файлов, это - не проблема.

И что? А то!

- Автоматическая целевая компиляция это не панацея, а решение конкретной задачи написания приложений определенного вида, используя FORTH-заготовки столь же определенного вида.
- Ручная целевая компиляция будет длиться столько, сколько вы будете писать на FORTH.
- Для того, чтобы эта ситуация изменилась, нужно либо научиться описывать на формальном языке те решения, которые мы принимаем на этапе 0, либо перейти на уровень выше, научив разом все наши FORTH-ы какому-то языку обмена идеями.
avatar
Gudleifr
Admin

Сообщения : 725
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Написание своего FORTH

Сообщение автор Gudleifr в Пт Июн 30, 2017 8:13 pm

СТОИТ ЛИ ИЗУЧАТЬ-ПИСАТЬ FORTH?
Начну очень издалека. Всем уже надоели попытки сравнить FORTH как с языками ассемблеров, так и с Algol-подобными. А если сравнить с интерпретаторами? Perl, Python... В чем-то очень мощные, местами забавные... Не говоря уже о том, что когда мне надо срочно слепить что-то работающее, без раздумий беру Perl.
Вот, от последнего факта и оттолкнусь. Быстро слепить что-то по-быстрому, пожалуйста... И Perl, и Python... Даже, если, кажется, что быстро написать не удастся, т.к. требуется изобрести какой-то механизм, то очень вероятно, что кто-то его уже реализовал и оформил в виде библиотеки. Получается очень быстро и удобно.
А если задача большая? Ну не заложен в язык или библиотеку алгоритм того, что нам нужно. А он сложный... Смогут ли наши чемпионы программирования "на коленке" помочь написать большую программу своим "особым" "патентованным" методом?
Все большие программы на Perl и Python, которые я видел были написаны на "обычном C++" (скорее, даже на C), с редкими вкраплениями программистских лингвистических выпендрежей и хитрыми заплатками в тех местах, где Perl (Python) слишком уж сильно отличался от C++. Вклад всяких ассоциативных массивов, тьюплов, "маленьких машинок", декораторов и прочего с ростом программ становился все меньше и меньше... Не верите?

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

Проведите эксперимент. Прочтите, какие замечательные структуры данных предлагает Perl/Python. А теперь возьмите книгу Кнута или Ахо и компании и прочтите про то, какие структуры данных обычно могут необходимы программисту. Не правда ли, люди говорят на разных языках?

Т.о. эти два самых популярных интерпретатора удобнее для маленьких задач, чем для больших. А FORTH? Буквально недавно я понял, откуда исходит раздражение этими вечными FORTH-несуразностями: лишними стековыми операциями и проверками уже проверенных условий. FORTH не предназначен для маленьких задач!
Для маленькой задачи нам жалко тратить время на изобретение лексиконов, хочется побыстрее. Но FORTH - не Perl/Python, никто не позаботился снабдить его тысячей мелочей на все случаи жизни, и красиво быстро не получается.
Все это, конечно, разговор "за жизнь". Есть ли что-то кроме "понравилось/не понравилось"? Есть. Главное отличие - в доступности ядер этих языков для программиста. Нет, конечно исходники доступны, для Python так просто рекомендовано их изучить. Однако, я как-то долго и безуспешно пытал всех подряд питонистов, в каких таблицах и в каком порядке ищутся программой идентификаторы. "А зачем это знать?" - спрашивают. Наоборот, большинство из них оказалось совершенно неготовыми к тому, что в новой версии некоторые системные списки стали тьюплами, а некоторые тьюплы - итераторами. В Perl то же самое. Почему столько описаний, как заставить "маленькую машинку" что-то сделать, вместо того, что бы открыть этот конструктор конечных автоматов программисту? Вот и получается, что внутренности Perl/Python никому не интересны, т.к. пишущиеся на них задачи такого копания не окупают, а FORTH, наоборот, провоцирует на адаптацию своего нутра для облегчения условий работы над проектом. Более того, т.к. задача большая, а FORTH маленький, написание своего/нового FORTH часто оправдано. "Полдня потерять, потом за пять минут долететь".
***

Последнее замечание совсем уж философское: почему машина построенная человеком, всегда хуже живого организма? Даже если мы боги био- и нано-технологии... Дело в том, что перед организмом стоит одна задача - выжить, а перед машиной две - выжить и сделать для нас что-то полезное. Если организм решает свою задачу - он выживает, не выживает - значит не пригоден к решению задачи. А у машины - это две разные, не связанные задачи. А за двумя зайцами... Посмотрим на FORTH. Какая самая красивая программа на нем написана? Он сам... И кто-то до сих пор считает его не системой, а, всего лишь, языком?
***

Почему мое утверждение об ориентированности FORTH на решение сложных, а не простых, задач вызвало такое возмущение коллег (на кошачьем форуме)? Ответ прост. Программисты не любят больших задач! Причины понятны, Дейкстра их сформулировал еще 40 лет назад. Быть гениальным творцом чего-то внешне очень заумного, но внутренне очень простого, гораздо почетнее, чем числиться автором чего-то, что еще пяток лет придется доводить до ума.
Конечно, есть много начинающих, которые мечтают чем-то большом и светлом (обычно, новой игре), но большинство из них с этой мечтой и остаются. Успешные программисты - жертвы цехового метода обучения, начинавшие с того, что писали свои утилитки и подпрограммки, глядя, как это делает гуру. (Например, по Python я, вообще, не видел серьезных книг). А супер-успешные программисты вообще как начинали с чего-то очень простого и прикладного (например, с FoxBase, позднее - с FoxPro), так с ним и остаются на всю жизнь, обрастая учениками, и втюхивая где-попало свои студенческие наработки на страх окружающим.
Программисты также не любят создавать (и использовать) новые языки. Даже попадая в новую языковую среду они продолжают пытаться использовать старые парадигмы. Посмотрите, например, как питонисты согласны на любые ухищрения, чтобы остаться в рамках, усвоенных при C-программировании. Исключения лишь подтверждают правило, и в каждом "новом" языке от awk до PHP мы видим стремление сохранить С-синтаксис.
***

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

... программисты не любят сложных задач;
... программисты боятся новых языков;
... программисты стремятся рассуждать о способе решения (разбиения) задач в терминах пользователя, а не FORTH.
avatar
Gudleifr
Admin

Сообщения : 725
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Написание своего FORTH

Сообщение автор Gudleifr в Пт Июн 30, 2017 8:14 pm

ЕЩЕ ОДНА ЛАЗЕЙКА ДЛЯ ЛЮБИТЕЛЕЙ "ФОРТА НА ФОРТЕ"
На кошачьем форуме я столкнулся с забавной концепцией "двухэтажного Форт-а". Первый этаж - реализованный аппаратно и очень ограниченный. Второй - реализованный программно, настоящий. Для меня осталось совершенно непонятным:
- Если FORTH удобнее каждый раз писать заново, то зачем заранее ограничивать свои возможности применением специального "железа"? Если уж и разрабатывать "спецжелезо", то под ту же сверхзадачу, для которой и FORTH будет создаваться. Мало, что ли японцы насчитали забавных архитектур, изобретая свою "ЭВМ пятого поколения". А FORTH, на то и FORTH, чтобы ставиться на любое "железо".
- Почему аппаратно реализованный FORTH должен быть ограниченным? Почему надо аппаратно реализовывать именно мини-FORTH, а не машину, способную легко программно реализовать на ней мощный FORTH? Например, мучиться с аппаратным мини-стеком, если стек является, по-сути, вспомогательной структурой, практически не влияющей на быстродействие? Почему не снабдить наш процессор средствами, для создания любых стеков и (очень на них похожими) средствами для работы с массивами шитого кода?
avatar
Gudleifr
Admin

Сообщения : 725
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Написание своего FORTH

Сообщение автор Gudleifr в Пт Июн 30, 2017 8:15 pm

ЭВОЛЮЦИЯ ИЛИ ДЕГЕНЕРАЦИЯ?
Идею такого "усиления" FORTH тоже почерпнул на кошачьем форуме (нет, правильно они меня там тогда забанили). Берем чей-либо готовый FORTH и начинаем приращивать к нему какую-нибудь сверхвозможность (идея не новая, вспомним, хотя бы PatternFORTH). Не забываем, кстати, что Ч.Мур был заранее против. Вот только авторы с форума выбирают такие "сверхвозможности", которых, по их мнению, не хватает FORTH, чтобы стать "супер-языком". Конечно, что такое "супер-язык", каждый понимает по-своему, но обычно они сходятся на том, что нужно по новому стандартизировать работу со стеком (т.к. у "чайников", которыми все они остаются в душе, написание чего-либо нетривиального порождает огромное количество избыточных стековых операций), и на том, чтобы как-то научить FORTH более приличному синтаксису (я также обратил внимание, что "новые фортеры" стараются и на FORTH писать, используя C-парадигмы - от попыток явной типизации, до использования отступов в записи "операторов").
Тут, в отличие от предыдущего параграфа, где много чего не понимал (все-таки я больше математик, чем электронщик), я, наоборот, констатирую непонимание "новыми фортерами":
- того, что структуры FORTH (особенно, стек) предназначены для обеспечения его функционирования и расширения, а не для решения всех проблем, ставящихся перед создаваемыми на FORTH проблемно-ориентированными языками;
- того, что внутри практически всех применяемых сейчас в программировании парадигм лежит некоторый математический аппарат, смысл использования которого зачастую теряется, когда они копируют эти парадигмы формально;
- того, что придумывая новые синтаксисы для новых лексиконов и увлекаясь созданием "своих" интерпретаторов в обход FORTH-овскому "Циклу Управления", они вынуждены делегировать своей "надстройке" все больше свойств ядра FORTH, что в конце концов, приводит к написанию чисто "своего FORTH" и ненужности старого, использованного ими ядра.
avatar
Gudleifr
Admin

Сообщения : 725
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Написание своего FORTH

Сообщение автор Gudleifr в Сб Окт 28, 2017 12:39 pm

Как я не пытался рассуждать о модулях и уровнях FORTH, похоже, это тоже один из уклонов. Нет такой системы уровней, которую FORTH бы с легкостью не опроверг. И нет такого модуля, от которого FORTH не отказался бы с легкостью при появлении новых стандартов аппаратного и/или программного обеспечения.
Отталкиваться можно, пожалуй только от "уровней", естественно складывающихся по мере разработки именно этого FORTH (например, писание в кодах, на языке ассемблера или целевая компиляция могут дать совершенно другую картину), и от общей концепции применения (повторю, у меня это "имеем A (язык машины), пишем на нем на коленке за неделю язык F (FORTH), затем на нем - P (проблемно-ориентированный язык), отдаем последний пользователю для решения своих задач"). Получается табличка, по одной оси откладываем доступные в этот момент средства, по другой - преследуемые цели.
У меня вышло:

0. Уровень концепцииВыбор AПодбор/написание F-макросовОбоснование выбора с точки зрения P
1. Уровень кодовых словПисание на AИспользование F-макросовКуски на A, необходимые для P
2. Уровень интерпретатораОтладочные/интерфейсные куски на AF-интерпретатор в шитом кодеОбщие Р- и F-слова
3. Уровень текстового вводаA-ассемблерF-стандартРеализация P
4. Уровень вторичной F-машиныИнтерфейс с ОСВторичная F-машинаР-машина

Термин "вторичная F-машина" меня самого сначала удивил. Но чем дальше, тем более необходимым показалось его введение.
Фортеры спокон веку гордятся тем, что в FORTH-систему встроен интерпретатор текста, который позволяет за здорово живешь обрабатывать чуть ли не человеческий язык. Мол, что вам еще надо, кроме слов, разделенных пробелами? И, действительно, огромному числу прикладных языков ничего больше и не требуется...
Но...

... время от времени появляются фортеры, которые жаждут странного, например, языков с командами-литерами (BASIC-музыка, превращение стековых комментариев в язык стековых манипуляторов)...
... ОС часто ставит перед программистом задачу распознавать что-то непотребное, например, файлы со словами, разделенными запятыми; c-, lisp- и trac-программы; слова-команды в виде четверок msg-wnd-wpar-lpar...
... целевая компиляция требует создать новый FORTH (а заодно и - новый интерпретатор) в параллель старому...
... реализовав зародыш FORTH на специализированном процессоре, может захотеться его расширить...

Конечно, существует множество решений на такой случай: сделать векторными основополагающие слова, заранее создать умные словари, распознающие, что угодно и т.п...
Но...
Что такое "FORTH-машина"? Это простенькая инициализация и GOTO в точку входа цепочки шитого кода, связанную в кольцо (даже Цикл Управления не просматривается) и прицепленное где-то "сбоку" INTERPRET - набор из пятка очень машинно-зависимых и практически не связанных с остальным кодом процедур: ОК, СИМВОЛ, ВЫПОЛНИТЬ, КОМПИЛИРОВАТЬ, СЛЕДУЮЩИЙ... Кое-как можно разобрать только основные куски СИМВОЛ: EXPECT, WORD, FIND, NUMBER... Времена, когда INTERPRET составлял основу Цикла Управления давно канули в лету (как и сам Цикл Управления).
Так какого черта мы строим свой FORTH вокруг этого "интерпретатора"? Давно пора сделать наличие второй (третьей и т.д) "FORTH-машины" в рамках одной FORTH-системы нормой! И не надо никаких "переопределяемых слов" и "умных словарей": просто пишем еще один тупой набор тупых ОК', СИМВОЛ', ВЫПОЛНИТЬ', КОМПИЛИРОВАТЬ', СЛЕДУЮЩИЙ'... И вопрос не имеет ничего общего с многозадачностью, все это вполне может работать "по очереди".
avatar
Gudleifr
Admin

Сообщения : 725
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Написание своего FORTH

Сообщение автор Gudleifr в Вт Ноя 14, 2017 9:26 pm

Будь FORTH-система написана на голом железе или реализована в виде приложения под мощной ОС, она не выходит по своим возможностям за пределы обычного встроенного BASIC древних персональных компьютеров: худо-бедно работать с текстовой консолью и немножко - с файлами/устройствами.
В лучшем случае, FORTH имеет доступ к API ОС, под управлением которой работает.
***

Думаю, что не надо смешивать два вида FORTH-ификации ОС - "переписать все на FORTH" или "обеспечить работу в FORTH-стиле". Ведь, второе для нас важнее. В первую очередь, нас должны интересовать именно свойства ОС, имеющие отношение к программированию посредством FORTH-метода. Т.е. интерфейс пользователя-программиста.
***

Пусть у нас в наличии некоторая OC. Уровень ее нам не важен: может, полуразобранный Спектрум, может, MS Excel... Пусть это будет, даже, не ОС в полном смысле слова, для примера не важно. Нам важно, чтобы была "машина", управляемая нашими командами и для которой мы мечтаем писать программы.
Для определенности/понятности возьмем, например, MS-DOS. Теперь начнем "изобретать программирование".

0) Программирование нулевого уровня - ручной ввод команд одна за другой. В MS-DOS мы так и делали. Скопировать файл, запустить игру, почистить директорий...
1) Когда мы увидели, что набирать по одной команде лениво, мы начали писать командные файлы (скрипты) - несколько команд "упакованных в одну", возможно даже с какой-то примитивной логикой "если ошибка, то...".
2) Покопавшись в компьютерных журналах, мы узнали, что командные файлы можно научить не тупо выполнять "что прошито", но и спрашивать у пользователя "чего изволите?". Правда, изначально в DOS не было никаких средств для обращения к оператору, но их можно было легко создать или спереть готовые на стороне, не суть. Главное, что мы научились писать, как определил Мур "Программы с вводом".

Пропустим следующий этап и сразу перейдем к (4):

4) Мы стали системными программистами, и можем написать свой BASIC - систему, которая позволяет нам писать программы не на убогом командном языке MS-DOS, даже не знающем, что наш IBM PC может выводить на экран графику, а на крутой машине, умеющей работать с массивами и строками, бибикать ноты и рисовать цветные линии...
По сути, мы возвращаемся к (0), но уже на новом технологическом уровне - можем вводить мощные команды, писать продвинутые скрипты-программы и т.д.

Теперь заткнем дыру:

3) Мы ищем способ не только увязывать команды в скрипты, но и создавать новые простые команды (а, заодно, и способы обмена информацией и передачи управления между ними). Т.к. результатом (4) будет новый язык (проблемно-ориентированный), то есть большое искушение назвать то, что, мы делаем на этом этапе, FORTH.
Однако, как ни назови, несомненно одно: нам придется залезть внутрь нашей исходной MS-DOS машины. И начать писать не на исходном языке команд command.com, а в кодах (например, в debug.com). И большая часть нашего BASIC-интерпретатора будет в этих кодах и написана (хотя он и сможет обращаться к MS-DOS, например, для работы с файлами). В случае же использования FORTH-метода "отскок в коды" будет совсем невелик - всего десяток основополагающих слов. Но, все равно, будет.

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

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

Сообщения : 725
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Написание своего FORTH

Сообщение автор Спонсируемый контент


Спонсируемый контент


Вернуться к началу Перейти вниз

Вернуться к началу

- Похожие темы

 
Права доступа к этому форуму:
Вы не можете отвечать на сообщения