Forth
http://fforum.winglion.ru/

Nova Дневник разработчика
http://fforum.winglion.ru/viewtopic.php?f=58&t=3227
Страница 6 из 7

Автор:  Victor__v [ Пн дек 02, 2019 14:00 ]
Заголовок сообщения:  Re: Nova Дневник разработчика

Как же приятно взяться за форт спустя несколько месяцев!
Покопаться в своих либах. Попытаться понять их логику. А поняв, почикать их по самое нехочу, чтоб работало и стало проще.
Видимо, разработка на форте это не только принцип снизу вверх, но и принцип из дуба в берёзу (последняя тоньше, такое вот сравнение).

А теперь по изменениям.
Добавлено слово TEMP-OUT ( temp-voc -- ) убирает из стека контекста временный словарь и освобождает память под него. А то расплодилось в Нове временных словарей и все нужны :)
Описана внутри форта структура используемая для перехвата ошибок. Теперь её можно использовать не боясь обвинений в хаках. Что задокументировано, то не хак (c).

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

Понятно изложил мысль?

Автор:  F-MAP [ Пн дек 02, 2019 17:10 ]
Заголовок сообщения:  Re: Nova Дневник разработчика

Victor__v писал(а):
Как же приятно взяться за форт спустя несколько месяцев!
Покопаться в своих либах. Попытаться понять их логику. А поняв, почикать их по самое нехочу, чтоб работало и стало проще.
Видимо, разработка на форте это не только принцип снизу вверх, но и принцип из дуба в берёзу (последняя тоньше, такое вот сравнение).

А теперь по изменениям.
Добавлено слово TEMP-OUT ( temp-voc -- ) убирает из стека контекста временный словарь и освобождает память под него. А то расплодилось в Нове временных словарей и все нужны :)
Описана внутри форта структура используемая для перехвата ошибок. Теперь её можно использовать не боясь обвинений в хаках. Что задокументировано, то не хак (c).

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

Понятно изложил мысль?

NOTFOUND так много забирает времени при сборке... 5-ть 10-ть кило лишнего, сейчас никого не напугают..

Автор:  Victor__v [ Пн дек 02, 2019 17:21 ]
Заголовок сообщения:  Re: Nova Дневник разработчика

F-MAP писал(а):
NOTFOUND так много забирает времени при сборке... 5-ть 10-ть кило лишнего, сейчас никого не напугают..


Чё ито он много времени забирает? Я несколько не понял, проясните, будьте любезны

Автор:  Victor__v [ Вс дек 22, 2019 23:15 ]
Заголовок сообщения:  Re: Nova Дневник разработчика

Думаю, сделаю в Нове функцию печати (TYPE) пользовательским вектором для расширяемости.

А то решил повозиться тут с трансляцией JSON и обратил внимание, что скопировать тот или иной объект трудная задача, особенно если он вложенный.
Поэтому пришла в голову мысль:
Поскольку в ООП для JSON зашита функция печати, то механизм такой:
Перенаправить весь TYPE-вывод в строку (у нас получится классический json) и результат снова отранслировать!
Дело осталось за малым - научиться перенаправлять вывод вместо файла в строку и желательно не квадратно-гнездовым способом :shuffle;
Впрочем, это не сложно

Автор:  Hishnik [ Пн дек 23, 2019 00:09 ]
Заголовок сообщения:  Re: Nova Дневник разработчика

Victor__v писал(а):
Дело осталось за малым - научиться перенаправлять вывод вместо файла в строку и желательно не квадратно-гнездовым способом
Впрочем, это не сложно

Сделать >STR бывает полезно. Потом с этой строкой можно делать все, что обычно делают со строками.

Автор:  Victor__v [ Пн дек 23, 2019 18:36 ]
Заголовок сообщения:  Re: Nova Дневник разработчика

Сейчас в Нове используются 4 пространства:
Пр. кода (изначальное)
Пр. данных (строки и переменные)
Пр. словарных статей (хранение заголовков слов идоп. информации)

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

Мне тут подумалось, что должен быть механизм создания пространств.
Ведь по факту можно выделить ещё 2 пространства
Отдельное под переменные
Отдельное под лямбды и безымянные участки кода.

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

Что для этого нужно?
Пока опускаем насколько это вообще востребовано.

Для начала для механизма пространств нужно пространство, где должен функциклировать (c) этот механизм.

Зададим каждое пространство так:

STRUCT: space
CELL -- S>hash \ хешированое обозначение пространства
CELL -- S>start \ начало старта пространства
CELL -- S>end \ конец пространства
CELL -- S>xt \ код для корректности контроля пространств.
STRUCT;

Тогда пространства служебная информация будет распределена так:
Код (основное пр-во), Строки, Словарные статьи, Переменные, Лямбды

Соот-но у структуры словаря должны быть такие поля:
...
4 CELLS -- L>LLFA
CELL -- L>MFA \ смещение до указателя, по которому хранится указатель до пространства механизма пространств. А что вы хотели? Так проще организовать наследование.
CELL -- L>compFA
CELL -- L>notfoundFA

Сейчас в Нове с доп. полями сложнее.

Как выразить тогда слова

: DP \ должен возвращать указатель, где хранится HERE соотв. пространства. только для стандартных
0
BEGIN BEGIN
space *
CURRENT @ L>MFA @ @ + S>start EXIT
ALTERNATIVE: 1 AGAIN \ на данные
ALTERNATIVE: 2 AGAIN \ на слов. статьи

;


: HERE
0
BEGIN BEGIN
space *
DP + @ EXIT
ALTERNATIVE: 1 AGAIN \ на данные
ALTERNATIVE: 2 AGAIN \ на слов. статьи

а с остальными словами для управления пространствами придётся поизголяться :)


В итоге реализация механизма создания пространств разгрузит словарную структуру, сделает её чуть понятнее.
Соб-но даст возможность насотворять новые пространства.

Из недостатков: придётся повозиться со словами для работы с кодофайлом :)

Автор:  mOleg [ Вт дек 24, 2019 18:42 ]
Заголовок сообщения:  Re: Nova Дневник разработчика

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

Автор:  Victor__v [ Вт дек 24, 2019 20:44 ]
Заголовок сообщения:  Re: Nova Дневник разработчика

Где код этих хранилищ можно посмотреть в форке?
Желательно дайте путь до файлов)

И тогда уж скажите, что ещё интересного есть в форке)
А то мне вспоминается только настраеваемый поиск в словарях

Автор:  f02732 [ Чт дек 26, 2019 20:50 ]
Заголовок сообщения:  Re: Nova Дневник разработчика

Victor__v писал(а):
F-MAP писал(а):
NOTFOUND так много забирает времени при сборке... 5-ть 10-ть кило лишнего, сейчас никого не напугают..


Чё ито он много времени забирает? Я несколько не понял, проясните, будьте любезны

Мне вообще не нравится такой механизм обработки ненайденных слов поиском NOTFOUND в словаре. Чем он лучше простого векторизированноно определения, которое можно в любой момент изменить/восстановить без проблем, + нет лишних заголовков, + не тратится время на поиск одного и того же слова по несколько раз?

Автор:  Victor__v [ Пт дек 27, 2019 02:20 ]
Заголовок сообщения:  Re: Nova Дневник разработчика

f02732 писал(а):
Мне вообще не нравится такой механизм обработки ненайденных слов поиском NOTFOUND в словаре. Чем он лучше простого векторизированноно определения, которое можно в любой момент изменить/восстановить без проблем, + нет лишних заголовков, + не тратится время на поиск одного и того же слова по несколько раз?


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

Цитата:
+ не тратится время на поиск одного и того же слова по несколько раз?

Это в СПФ NOTFOUND каждый раз искался в словаре, в Nova просто прописано в поле, откуда обработчик берётся.

Автор:  Victor__v [ Пн авг 03, 2020 12:21 ]
Заголовок сообщения:  Re: Nova Дневник разработчика

Недавно выяснил, что у меня в потоках вылетает форт-система из-за WINAPI-оберток.

Воспользовавшись методом Чака Нориса (буравить взглядом исходник, пока он не выдаст всю информацию), понял в чем проблема.

У меня код-обертки (winapi-code) при своем вызове самомодифицируется на (stdcall).
Вот только для самомодификации используется переменная DP.

В чем прикол
DP дает указатель, где хранится HERE. Вот только это место у каждого словаря свое,
Код для понятности: : DP CURRENT @ L>hereFA @ ;
Вот.
А при создании потока текущий словарь не прописывается в пользовательской области!
Из-за этого при самомодификации код пытался получить значение переменной по недопустимому адресу!

В итоге поменял код с самомодификацией.
Короче, опять ввел в форт-систему слово RECOMPILE, которое компилирует вызов по адресу со стека данных.

Автор:  Victor__v [ Пн авг 10, 2020 15:25 ]
Заголовок сообщения:  Re: Nova Дневник разработчика

И снова по поводу потоков.

У меня сейчас в форте доступность пользовательских переменных в каллбеке реализована через сохранение указателя
в области TIB, что в винде.
Недостаток такого выкрутаса - портируемость.
Если переводить Нову на другую ОС, то этот код надо будет менять, да и 64 разрядом та же фигня.

Поэтому решил реализовать эту поддержку непосредственно средствами форта, не полагаясь на малодокументированные свойства Винды и архитектуры процессора.

Решил поступить просто:
Завести переменную, в которую все потоки будут вписывать указатели на свои пользовательские области.
Калбеку соответственно для доступа к юзверям надо будет узнать идентификатор потока, в котором он выполняется, и запросить указатель на юзверей.

Делов-то 3 слова написать: TLS-SAVE TLS-RESTORE TLS-DELETE ну и переменная, где хранятся все айдишки с указателями.

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

Автор:  Victor__v [ Пт сен 18, 2020 11:37 ]
Заголовок сообщения:  Re: Nova Дневник разработчика

Как упростить Нову.

Может попробовать хранить указатели на пространства данных в TIB?

Код доступа к адресу тогда в нативе будет
что-то вроде
FS: MOV EAX, [100]
LEA EAX, [20+EAX]

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

Однако всплывает недостаток в другом месте - у временных словарей данных хранятся отдельно, что логично. И как тогда указатели на них хранить в FS (GS)?

Самый очевидный (относительно) способ решить проблему - оставить реализацию в врем. словарей как есть, а данные основного пространства в TIB?

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

Вот такие вот заметки на полях

Автор:  Victor__v [ Ср сен 23, 2020 18:45 ]
Заголовок сообщения:  Re: Nova Дневник разработчика

начал портировать под 64 бита среднеуровневые слова форта ( в основном те, которые компилируют нативный код).

Скажем так, слово RECOMPILE получилось переусложненным.

Итак рассмотрим возможные состояния для перекомпиляции:
новый код недалеко от места, куда его надо засунуть ( т. е. расстояние 0x80000000)
- все просто делаем как в 32-битной версии.

новый код далеко от места, куда его надо всунуть, а в месте использован длинный вызов кода.
- просто переписываем длинный вызов.

новый код далеко от места, куда его надо всунуть, а в месте использован обычный вызов кода.
- а вот тут я хрен знает. Впихнуть невпихуемое оч. проблематично (обычный вызов 5 байт, длинный 12). Пока поставил исключение на случай появления такой ситуевины.

И вот как её разрешить?
Поскольку все мы помним закон Мерфи? Если хрень может случиться, то она обязательно случится. :weep;

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

Код:
MOV RBX, code
CALL RBX

Автор:  mOleg [ Ср сен 23, 2020 19:18 ]
Заголовок сообщения:  Re: Nova Дневник разработчика

переходы внутри одного определения - короткие,
между определениями - длинные.
имхо

Страница 6 из 7 Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/