https://yadi.sk/d/f5mT9b-UwUVrp
Что имеется в наличии?
Имеются две вещи.
1) работа со строками, которые хранятся на стеке возвратов. Память "освобождается" автоматически (снимается резервирование стека).
2) Препроцессор в виде временного словаря.
Используется так: s" my-file.f" prep\pre3
my-file.f будет просмотрен препроцессором. Определения макросов в коде будут скомпилированы во временный словарь препроцессора. После обработки файла препроцессор самоудаляется.
Директивы (форт-слова) :
m#def создаёт определение, которое будет развёрнуто по evaluate
Пример m#def [h] ( [ hex ] )
macro: - создаёт слово немедленного исполнения во временном словаре. Определение должно заканчиваться macro;
+PRE{ после этого слова все последующие слова переносятся в обитель препроцессора. Должно заканчиваться }PRE+

Перед загрузкой нужного файла, препроцессор подгружает макросы, пути к которым определены в preproc\macro+.txt
На данный момент подгружаются
простейшие лямбды
доп.операции над стеком возвратов
несколько слов для обрезания строк.
преобразователь строк в числа ( S" 0000" превращается 0x30303030 )
Преобразователь кода в числа ( надо было для понятной последующей компиляции лямбд для строк и лок.переменных)
Локальные переменные на стеке возвратов (доступ по номеру), можно использовать в циклах
notfound препроцессора с возможностью подключения обработчиков.
Расширение для локальных переменных - возможность писать L0 L1 L^2 и т.д. работает через notfound
Снова расширение для лок.переменных - возможность именовать переменные, работает через notfound
Работа со строками на стеке возвратов ( см. п.1)
Отличия: возможность экранировать кавычку \" , можно определить пустую строку ( R:STR 300 "" )
Локальные переменные совместимы с данной библиотекой
Парсер сцепленного форт-кода. Чтобы последний меньше места в блокноте занимал. работает через notfound
Не работает с числами, потом доделаю. Пример: =IF ICELLS LEAVETHEN превращается в = IF I CELLS LEAVE THEN

Великолепно, но комментарии в исходниках увеличат ценность ваших трудов в разы!

Комментарии есть, правда местами
В любом случае, самое полезное это операции со строками. А там всё более-менее великолепно

Сейчас в процессе:
Второй препроцессор. Работает по принципу "от сих до сих" . Основное назначение сокрытие деталей. Парсит текст до ключевого слова, вычленяет макросы, создаёт временный словарь и компилирует туда макросы.
Болезненно совместим с уже ставшим стандартным препроцессором, ибо кто-то из них мешает работе другого.
Какая-то проблема со списком словарей у них возникает.
Поэтому второй препроцессор будет переделываться в чисто текстовый.

Оптимизирующий парсер. В интернете оптимизацию кода на этапе парсинга не нашёл. И не понятно почему. Наверно, из-за синтаксической сложности многих языков.
Итак, парсим текст до ключевого слова, вычленяем все слова по ходу дела и их адреса укладываем в массив. Если это число, то укладываем -1 и само число. Если что-то иное, пусть с этим разбираются обработчики, коих пока нет.
Далее, создаём структуры типичных ситуаций.
К примеру, превратится в
Через что это будет работать? Пока не решил, скорее всего часть кода будет сразу компилироваться, а остальная через evaluate .
Зачем это надо?
Хочется создать свою форт-систему, а оптимизатор вещь полезная, но громоздкая и фиг-его-знает-как-расширяемая. Поэтому создаём аналог оптимизатора СПФ

В темах от OCO AVRForth, m3Forth (раздел Форт для микроконтроллеров) есть оптимизация текстового представления Форт программ (по аналогии SwiftForth). Можно встретить и в каких то других Фортах (для PIC) и например в проекте кросс Форт подобного компилятора ForthEC (язык реализации Euphoria). В FF303 тоже есть определённая реализация подобной техники.
В проектах Forth -> C тоже есть методики подобых оптимизаций. (например в проекте Timbre от Rob Chapman)

P.S. Какие то ещё могут быть полезные прототипы, если "углубится" в данной тематике.

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

Ещё одна немаловажная проблема: написание обработчиков не является достаточно простым занятием. Нужен более автоматический поиск по шаблону. Допустим SUBLIST? ( s1 s2 ... sn n -- addr-elem|0 ) , где s1 s2 и т.д. строки со счётчиком. Или ещё более продвинутый вычленятель списка.

https://vk.com/doc189457568_439681951
Что нового?
1) Добавлена новая библиотека для работы со списками.
Принцип работы: перед началом работы инициализируется куча, где и будут существовать элементы. Адресация относительная. По этой причине объём среды обитания списка можно регулировать. Библиотека работоспособна. Практика покажет, что ещё необходимо. А необходимость кое-в-чём возникла. А именно в вычленении последовательности элементов из списка.
Думаю, решать надо как-то сопрограммно, относительно конечно.
По условию на стек возвратов словом XT-LIST укладываются три значения: начало хипа под список, адрес элемента, код, который надо будет исполнить над каждым элементом.
Т.к. xt наверху стека возвратов, то слово с этим xt будет относительно легко менять, собственно, xt.

где co-ret меняет xt на след.позицию, а end-ret посылает сообщение слову XT-LIST, что работа закончена и пора "чистить сейвы"
Данный код выведет указатели на элементы которые равны 10 9 8. Они могут быть соседями или поодаль неважно. По крайней мере, данный "сопрограммный" способ позволяет работать чуть более удобно.

2) написана маленькая (2000 с лишним байт) урезанная форт-система в виде библиотеки для СПФ, называется Fj
Сделана была просто так. Чисто интерпретатор. можно пользоваться циклами и условиями.
Вот и все преимущества перед СПФ в режиме интерпретации.
Некомпилируемый, но может компилировать
Зачем нужна? Самому интересно. Но поддержка циклов и условий в режиме интерпретации выглядят достаточно полезными
Думаю, время подскажет.
Синтаксис Fj проще синтаксиса самого форта. В Fj всего одно правило: любая команда это 2 символа. Всё. Пробелами разделять даже не надо. Разумеется, есть команды которые управляют трансляцией. Как же без них.

Пока в работе над списками в куче.
"Сопрограммная" реализация для действий над списком может посылать словам XT-LIST и XT-subLIST сообщения об окончании работы через стек возвратов. Т.е. подменить в раннее обозначенных словах xt на 0, что приведёт к выходу из цикла.
Текущие проблемы: надо что-то делать с списковыми словами.
Если раньше написание на асме делалось ради скорости и размера кода, то теперь некоторые слова проще писать на асме, чем на форте, если не считать переходов.
Как я понимаю, после возможного перехода регистр флагов должен обновляться, командой add например. Как иначе?
Надоело пользоваться JECXZ.

https://vk.com/doc189457568_439942879
Ускорен (слегка) язык Fj, теперь сидит и ждёт проверки трудом.
Библиотека для списков обогатилась новыми словами (дать пред.элемент, удалить элементы..)
Хочу заметить, что каждое обновление работоспособно. Всё идёт к наращиванию функционала
Что позволило "активировать" оптимизирующий парсер.
Пока затестил то, что оптимизатор СПФ игнорировал:
0 >r


rdrop rdrop rdrop и т.д.


Последний вариант быстрее работает. Но если надо удалить только один элемент, то add быстрее. Парсер это также учитывает.

Написал несколько обработчиков для оптимизирующего парсера.
Пока думаю над оптимизацией if-else-then
Сейчас сделана оптимизация if-then
Метод действия:
найти if узнать тип перехода ( пока только jne),
найти then вычислить расстояние между ними.
выделить память в хипе перенести here на начало хипа.
Скомпилировать отрезок.
Узнать длину полученного кода.
Освободить память.
Подставить полученную длину к переходу.
Хотел вместо выделения отрезка использовать временный словарь, но какая-то проблема с препроцессором насчёт current, поэтому оставил этот урезанный вариант.

https://vk.com/doc189457568_440355470
Написал обработчик переходов else-then
Теперь за условия спокоен.
Проверил также на вложенность. При двойной вложенности всё в порядке.
Написал ещё пару простых обработчиков.
На очереди оптимизации слова IF.
Равно числу, больше числа и так далее.

Поправил препроцессор ( слова macro: и macro; теперь хранят контекст в переменной, а не на стеке )
Поэтому компиляция отрезков ( см. Пт дек 23, 2016 17:57) происходит во временный словарь, со всеми нужными его плюшками.

Попробовал построить более вариативный обработчик IF . Получилось. Да так хорошо, что решил его улучшить. Теперь этот обработчик способен оптимизировать 8 вариантов кода. Пока рекорд.
Обработчик также перекрыл ранее написанные. Отключил их.
С ним пришлось повозиться. Цена вариативности усложнение структуры разбора. И в качестве хранилища выступает только стек данных.
Благодаря прямому вмешательству обработчиков в слова XT-LIST XT-subLIST , обработчики могут хоть менять свой адрес, хоть перезапускать цикл сначала. Но из-за прямого доступа применение стека возвратов ограничено каждым "возвратом управления".
А учитывая кол-во отсекаемых вариантов, писать 2drop пять раз к ряду не катит.
Хоть садись и пиши планировщик ( в данном случае перенаправлятель)
Но, думаю, для написания обработчиков использовать планировщик сопрограмм слишком жирно или нет?
Да и сопрограмм, пусть и условных, всего две, а то и полторы

https://vk.com/doc189457568_441278315
Что нового?
Подправил препроцессор.
Написал простой планировщик сопрограмм. Для хранения и переключения задач используется регистр edi . Ибо в СПФ программы его не трогают. Во время действия сопрограмм доступ к переменным потока осложнён, но всё же возможен. Существует в среднем и асм.варианте. Последний, ест-но, быстрее, и стек меньше трогает. Стеки общие.
Написал несколько оптимизаций, чуток изменил сам парсер. По организации он достаточно простой и расширяемый.
насчёт оптимизации while-перехода возникли сложности. Поэтому не трогаю данный аспект.
Ещё один немаловажный момент, это оптимизация нестандартных структур управления.
Себя-то я знаю. Они есть и будут. и с ними надо что-то делать. Ибо они в лучшем случае собьют оптимизацию.

Оптимизировал связку begin while repeat
Теперь связка превращается, схематично, в begin jmp again jmp_mark
Всё это дело компилируется во временный словарь, в котором вычисляется значение для прыжка.

Написал вариативную оптимизацию под while
Оптимизация 16 вариантов, если включить сюда длину перехода
Оптимизируемая связка - (dup)-num-cond-while
Расшифровка: dup может присутствовать или не присутствовать, далее любое число, далее стандартное условие ( = <> < >) и в конце while

Есть мысль создать форт-систему со стеком исключений.
Как вариант отдать под это 31 ячейку. а главным за этот стек назначить регистр EDI
Также с его помощью адресовать user-переменные, под которые выделить 2 кб на стеке возвратов.
Итак, общая картина:
r: user-область ... стек-исключений ... стек-данных ... адреса-возврата
В связи с этим пара вопросов.
Так ли часто используется механизм перехвата исключений?
Насколько часто он будет использоваться, если его расширить ( try ecept finaly )?
Хватит ли двух кб под юзверей для функционирования многопоточного форта, если учесть что чуть более 1 кб уже занято?