Forth http://fforum.winglion.ru/ |
|
Наработки от victor__v для СПФ http://fforum.winglion.ru/viewtopic.php?f=23&t=3105 |
Страница 1 из 6 |
Автор: | Victor__v [ Сб окт 08, 2016 19:13 ] |
Заголовок сообщения: | Наработки от victor__v для СПФ |
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 |
Автор: | Ilya [ Сб окт 08, 2016 21:08 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
Victor__v писал(а): Великолепно, но комментарии в исходниках увеличат ценность ваших трудов в разы! |
Автор: | Victor__v [ Сб окт 08, 2016 22:31 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
Цитата: Великолепно, но комментарии в исходниках увеличат ценность ваших трудов в разы! Комментарии есть, правда местами В любом случае, самое полезное это операции со строками. А там всё более-менее великолепно |
Автор: | Victor__v [ Пн окт 17, 2016 21:51 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
Сейчас в процессе: Второй препроцессор. Работает по принципу "от сих до сих" . Основное назначение сокрытие деталей. Парсит текст до ключевого слова, вычленяет макросы, создаёт временный словарь и компилирует туда макросы. Болезненно совместим с уже ставшим стандартным препроцессором, ибо кто-то из них мешает работе другого. Какая-то проблема со списком словарей у них возникает. Поэтому второй препроцессор будет переделываться в чисто текстовый. Оптимизирующий парсер. В интернете оптимизацию кода на этапе парсинга не нашёл. И не понятно почему. Наверно, из-за синтаксической сложности многих языков. Итак, парсим текст до ключевого слова, вычленяем все слова по ходу дела и их адреса укладываем в массив. Если это число, то укладываем -1 и само число. Если что-то иное, пусть с этим разбираются обработчики, коих пока нет. Далее, создаём структуры типичных ситуаций. К примеру, Код: ['] lit, ['] ] ['] >r превратится в Код: 0xb9 c, , 0x51 c, ] Через что это будет работать? Пока не решил, скорее всего часть кода будет сразу компилироваться, а остальная через evaluate . Зачем это надо? Хочется создать свою форт-систему, а оптимизатор вещь полезная, но громоздкая и фиг-его-знает-как-расширяемая. Поэтому создаём аналог оптимизатора СПФ |
Автор: | KPG [ Вт окт 18, 2016 15:30 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
Victor__v писал(а): Хочется создать свою форт-систему, а оптимизатор вещь полезная, но громоздкая и фиг-его-знает-как-расширяемая. Поэтому создаём аналог оптимизатора СПФ В темах от OCO AVRForth, m3Forth (раздел Форт для микроконтроллеров) есть оптимизация текстового представления Форт программ (по аналогии SwiftForth). Можно встретить и в каких то других Фортах (для PIC) и например в проекте кросс Форт подобного компилятора ForthEC (язык реализации Euphoria). В FF303 тоже есть определённая реализация подобной техники. В проектах Forth -> C тоже есть методики подобых оптимизаций. (например в проекте Timbre от Rob Chapman) P.S. Какие то ещё могут быть полезные прототипы, если "углубится" в данной тематике. |
Автор: | Victor__v [ Ср ноя 16, 2016 11:20 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
попробовал сделать оптимизирующий парсер. Получилось. На данный момент исходный текст разбивается на слова. Слова-строки заносятся в список. обработчики-оптимизаторы работают с этим списком и модернизируют его. А потом каждый элемент списка раскручивается по evaluate. Медленно, но зато просто. Потом исправлю. Текущие проблемы: Организация списков. Особая тема. Элементы списка обитают в стеке возвратов. Сделано, дабы не реализовывать сборщик мусора. Который при другом раскладе надо было б писать. Напоминаю, уровень задачи средний. Но это порождает ряд специфичных проблем. Первейшая проблема - необходимость перетряхивать стек, когда строишь список во вложенном вызове. Решаемо, но немного неприятно каждый раз этим заниматься. Вторая беда - кое-какие вещи трудно реализовывать. К примеру, нет слова с действием "создать и вставить произвольное кол-во элементов, данные которых на стеке, в список по индексу/адресу элемента списка". Реализовать-то можно, но как это сделать без доп.средств/библиотек? Ещё одна немаловажная проблема: написание обработчиков не является достаточно простым занятием. Нужен более автоматический поиск по шаблону. Допустим SUBLIST? ( s1 s2 ... sn n -- addr-elem|0 ) , где s1 s2 и т.д. строки со счётчиком. Или ещё более продвинутый вычленятель списка. |
Автор: | Victor__v [ Пт дек 09, 2016 20:18 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
https://vk.com/doc189457568_439681951 Что нового? 1) Добавлена новая библиотека для работы со списками. Принцип работы: перед началом работы инициализируется куча, где и будут существовать элементы. Адресация относительная. По этой причине объём среды обитания списка можно регулировать. Библиотека работоспособна. Практика покажет, что ещё необходимо. А необходимость кое-в-чём возникла. А именно в вычленении последовательности элементов из списка. Думаю, решать надо как-то сопрограммно, относительно конечно. По условию на стек возвратов словом XT-LIST укладываются три значения: начало хипа под список, адрес элемента, код, который надо будет исполнить над каждым элементом. Т.к. xt наверху стека возвратов, то слово с этим xt будет относительно легко менять, собственно, xt. Код: примерный код: : test dup @ 10 = if co-ret else drop exit then dup @ 9 = if co-ret else drop exit then dup @ 8 = if end-ret else drop then ; где co-ret меняет xt на след.позицию, а end-ret посылает сообщение слову XT-LIST, что работа закончена и пора "чистить сейвы" Данный код выведет указатели на элементы которые равны 10 9 8. Они могут быть соседями или поодаль неважно. По крайней мере, данный "сопрограммный" способ позволяет работать чуть более удобно. 2) написана маленькая (2000 с лишним байт) урезанная форт-система в виде библиотеки для СПФ, называется Fj Сделана была просто так. Чисто интерпретатор. можно пользоваться циклами и условиями. Вот и все преимущества перед СПФ в режиме интерпретации. Некомпилируемый, но может компилировать Зачем нужна? Самому интересно. Но поддержка циклов и условий в режиме интерпретации выглядят достаточно полезными Думаю, время подскажет. Синтаксис Fj проще синтаксиса самого форта. В Fj всего одно правило: любая команда это 2 символа. Всё. Пробелами разделять даже не надо. Разумеется, есть команды которые управляют трансляцией. Как же без них. Код: простой пример
ALSO Fj 2N102N05DOI|..LP PREVIOUS |
Автор: | Victor__v [ Чт дек 15, 2016 00:03 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
Пока в работе над списками в куче. "Сопрограммная" реализация для действий над списком может посылать словам XT-LIST и XT-subLIST сообщения об окончании работы через стек возвратов. Т.е. подменить в раннее обозначенных словах xt на 0, что приведёт к выходу из цикла. Текущие проблемы: надо что-то делать с списковыми словами. Если раньше написание на асме делалось ради скорости и размера кода, то теперь некоторые слова проще писать на асме, чем на форте, если не считать переходов. Как я понимаю, после возможного перехода регистр флагов должен обновляться, командой add например. Как иначе? Надоело пользоваться JECXZ. |
Автор: | Victor__v [ Сб дек 17, 2016 13:04 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
https://vk.com/doc189457568_439942879 Ускорен (слегка) язык Fj, теперь сидит и ждёт проверки трудом. Библиотека для списков обогатилась новыми словами (дать пред.элемент, удалить элементы..) Хочу заметить, что каждое обновление работоспособно. Всё идёт к наращиванию функционала Что позволило "активировать" оптимизирующий парсер. Пока затестил то, что оптимизатор СПФ игнорировал: 0 >r Код: Как делает СПФ MOV FC [EBP] , EAX XOR EAX , EAX PUSH EAX MOV EAX , FC [EBP] Как делает парсер xor ecx, ecx push ecx rdrop rdrop rdrop и т.д. Код: Как делает СПФ add esp, # 12 Как делает парсер lea esp, 12 [esp] Последний вариант быстрее работает. Но если надо удалить только один элемент, то add быстрее. Парсер это также учитывает. |
Автор: | Victor__v [ Пт дек 23, 2016 18:57 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
Написал несколько обработчиков для оптимизирующего парсера. Пока думаю над оптимизацией if-else-then Сейчас сделана оптимизация if-then Метод действия: найти if узнать тип перехода ( пока только jne), найти then вычислить расстояние между ними. выделить память в хипе перенести here на начало хипа. Скомпилировать отрезок. Узнать длину полученного кода. Освободить память. Подставить полученную длину к переходу. Хотел вместо выделения отрезка использовать временный словарь, но какая-то проблема с препроцессором насчёт current, поэтому оставил этот урезанный вариант. |
Автор: | Victor__v [ Вт дек 27, 2016 20:19 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
https://vk.com/doc189457568_440355470 Написал обработчик переходов else-then Теперь за условия спокоен. Проверил также на вложенность. При двойной вложенности всё в порядке. Написал ещё пару простых обработчиков. На очереди оптимизации слова IF. Равно числу, больше числа и так далее. |
Автор: | Victor__v [ Чт дек 29, 2016 19:40 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
Поправил препроцессор ( слова macro: и macro; теперь хранят контекст в переменной, а не на стеке ) Поэтому компиляция отрезков ( см. Пт дек 23, 2016 17:57) происходит во временный словарь, со всеми нужными его плюшками. Попробовал построить более вариативный обработчик IF . Получилось. Да так хорошо, что решил его улучшить. Теперь этот обработчик способен оптимизировать 8 вариантов кода. Пока рекорд. Обработчик также перекрыл ранее написанные. Отключил их. С ним пришлось повозиться. Цена вариативности усложнение структуры разбора. И в качестве хранилища выступает только стек данных. Благодаря прямому вмешательству обработчиков в слова XT-LIST XT-subLIST , обработчики могут хоть менять свой адрес, хоть перезапускать цикл сначала. Но из-за прямого доступа применение стека возвратов ограничено каждым "возвратом управления". А учитывая кол-во отсекаемых вариантов, писать 2drop пять раз к ряду не катит. Хоть садись и пиши планировщик ( в данном случае перенаправлятель) Но, думаю, для написания обработчиков использовать планировщик сопрограмм слишком жирно или нет? Да и сопрограмм, пусть и условных, всего две, а то и полторы |
Автор: | Victor__v [ Сб янв 21, 2017 12:32 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
https://vk.com/doc189457568_441278315 Что нового? Подправил препроцессор. Написал простой планировщик сопрограмм. Для хранения и переключения задач используется регистр edi . Ибо в СПФ программы его не трогают. Во время действия сопрограмм доступ к переменным потока осложнён, но всё же возможен. Существует в среднем и асм.варианте. Последний, ест-но, быстрее, и стек меньше трогает. Стеки общие. Написал несколько оптимизаций, чуток изменил сам парсер. По организации он достаточно простой и расширяемый. насчёт оптимизации while-перехода возникли сложности. Поэтому не трогаю данный аспект. Ещё один немаловажный момент, это оптимизация нестандартных структур управления. Себя-то я знаю. Они есть и будут. и с ними надо что-то делать. Ибо они в лучшем случае собьют оптимизацию. |
Автор: | Victor__v [ Чт янв 26, 2017 20:58 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ |
Оптимизировал связку begin while repeat Теперь связка превращается, схематично, в begin jmp again jmp_mark Всё это дело компилируется во временный словарь, в котором вычисляется значение для прыжка. Написал вариативную оптимизацию под while Оптимизация 16 вариантов, если включить сюда длину перехода Оптимизируемая связка - (dup)-num-cond-while Расшифровка: dup может присутствовать или не присутствовать, далее любое число, далее стандартное условие ( = <> < >) и в конце while |
Автор: | Victor__v [ Вс мар 12, 2017 16:21 ] |
Заголовок сообщения: | Re: Наработки от victor__v для СПФ идеи форт-системы |
Есть мысль создать форт-систему со стеком исключений. Как вариант отдать под это 31 ячейку. а главным за этот стек назначить регистр EDI Также с его помощью адресовать user-переменные, под которые выделить 2 кб на стеке возвратов. Итак, общая картина: r: user-область ... стек-исключений ... стек-данных ... адреса-возврата В связи с этим пара вопросов. Так ли часто используется механизм перехвата исключений? Насколько часто он будет использоваться, если его расширить ( try ecept finaly )? Хватит ли двух кб под юзверей для функционирования многопоточного форта, если учесть что чуть более 1 кб уже занято? |
Страница 1 из 6 | Часовой пояс: UTC + 3 часа [ Летнее время ] |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |