Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Вт май 26, 2020 01:17

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Ответить
Имя пользователя:
Заголовок:
Текст сообщения:
Введите текст вашего сообщения. Длина сообщения в символах не более: 60000

Размер шрифта:
Цвет шрифта
Настройки:
BBCode ВКЛЮЧЕН
[img] ВЫКЛЮЧЕН
[flash] ВЫКЛЮЧЕН
[url] ВКЛЮЧЕН
Смайлики ВЫКЛЮЧЕНЫ
Отключить в этом сообщении BBCode
Не преобразовывать адреса URL в ссылки
Вопрос
Теперь гостю придется вводить здесь пароль. Не от своей учетной записи, а ПАРОЛЬ ДЛЯ ГОСТЯ, получить который можно после регистрации на форуме через ЛС.:
Этот вопрос предназначен для выявления и предотвращения автоматических регистраций.
   

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


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

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

Это в СПФ NOTFOUND каждый раз искался в словаре, в Nova просто прописано в поле, откуда обработчик берётся.
Сообщение Добавлено: Пт дек 27, 2019 02:20
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
Victor__v писал(а):
F-MAP писал(а):
NOTFOUND так много забирает времени при сборке... 5-ть 10-ть кило лишнего, сейчас никого не напугают..


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

Мне вообще не нравится такой механизм обработки ненайденных слов поиском NOTFOUND в словаре. Чем он лучше простого векторизированноно определения, которое можно в любой момент изменить/восстановить без проблем, + нет лишних заголовков, + не тратится время на поиск одного и того же слова по несколько раз?
Сообщение Добавлено: Чт дек 26, 2019 20:50
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
Где код этих хранилищ можно посмотреть в форке?
Желательно дайте путь до файлов)

И тогда уж скажите, что ещё интересного есть в форке)
А то мне вспоминается только настраеваемый поиск в словарях
Сообщение Добавлено: Вт дек 24, 2019 20:44
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
у меня оно называется хранилищами.
Вот так, думаешь, реализуешь, рассказываешь другим, а потом наслаждаешься наблюдениями за другим изобретающим то же 8)
Сообщение Добавлено: Вт дек 24, 2019 18:42
  Заголовок сообщения:  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 \ на слов. статьи

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


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

Из недостатков: придётся повозиться со словами для работы с кодофайлом :)
Сообщение Добавлено: Пн дек 23, 2019 18:36
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
Victor__v писал(а):
Дело осталось за малым - научиться перенаправлять вывод вместо файла в строку и желательно не квадратно-гнездовым способом
Впрочем, это не сложно

Сделать >STR бывает полезно. Потом с этой строкой можно делать все, что обычно делают со строками.
Сообщение Добавлено: Пн дек 23, 2019 00:09
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
Думаю, сделаю в Нове функцию печати (TYPE) пользовательским вектором для расширяемости.

А то решил повозиться тут с трансляцией JSON и обратил внимание, что скопировать тот или иной объект трудная задача, особенно если он вложенный.
Поэтому пришла в голову мысль:
Поскольку в ООП для JSON зашита функция печати, то механизм такой:
Перенаправить весь TYPE-вывод в строку (у нас получится классический json) и результат снова отранслировать!
Дело осталось за малым - научиться перенаправлять вывод вместо файла в строку и желательно не квадратно-гнездовым способом :shuffle;
Впрочем, это не сложно
Сообщение Добавлено: Вс дек 22, 2019 23:15
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
F-MAP писал(а):
NOTFOUND так много забирает времени при сборке... 5-ть 10-ть кило лишнего, сейчас никого не напугают..


Чё ито он много времени забирает? Я несколько не понял, проясните, будьте любезны
Сообщение Добавлено: Пн дек 02, 2019 17:21
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
Victor__v писал(а):
Как же приятно взяться за форт спустя несколько месяцев!
Покопаться в своих либах. Попытаться понять их логику. А поняв, почикать их по самое нехочу, чтоб работало и стало проще.
Видимо, разработка на форте это не только принцип снизу вверх, но и принцип из дуба в берёзу (последняя тоньше, такое вот сравнение).

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

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

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

NOTFOUND так много забирает времени при сборке... 5-ть 10-ть кило лишнего, сейчас никого не напугают..
Сообщение Добавлено: Пн дек 02, 2019 17:10
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
Как же приятно взяться за форт спустя несколько месяцев!
Покопаться в своих либах. Попытаться понять их логику. А поняв, почикать их по самое нехочу, чтоб работало и стало проще.
Видимо, разработка на форте это не только принцип снизу вверх, но и принцип из дуба в берёзу (последняя тоньше, такое вот сравнение).

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

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

Понятно изложил мысль?
Сообщение Добавлено: Пн дек 02, 2019 14:00
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
Всё-таки пора переходить на 64 бита.
А то у нас тут на форуме их нема. Только Кварк Хищника.
Мало товарисчи, мало :D

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

Меньший затык:
Надо написать обёртку на fastcall в винде.

Сейчас добавил в форт слова DW@ DW! DW,
От слов @ ! , сейчас ничем не отличаются. 32-бит всё-таки.
Просто задел на будущее.

Ввёл слово SSET-OUT т. е. убрать элемент из множества на стеке.
С такой операцией гораздо проще писать самоудаляторы библиотек.
Сообщение Добавлено: Вт окт 01, 2019 14:40
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
Очередной виток идей для улучшения форта, поскольку реальной задачи у меня всё равно нет :(

1) Промежуточная стадия компиляции.
Т. е. код компилируется не в натив, а в энн-ый набор структур, к которым уже применяются оптимизирующие правила.
Недостаток не предусматривает расширяемости. Если кому-то придёт в голову использовать в определении ассемблерные ставки, то они могут после тупо затереться. Также нужно приложить сильное колдунство, чтобы учитывались компилирующие эффекты некоторых слов.

1.1)
Очередной вариант оптимизатора. Ну вот люблю я их делать а после выкидывать на помойку)
Алгоритм:
Отслеживаем каждое слово, записываем все данные о нём в массив структур и компилируем/исполняем его. И так всё вплоть до слова ;
Это слово по сути является спусковым крючком.
Далее просматриваем весь массив элементов и ищем разрывы в коде между элементами. Так мы попробуем определить не-слова (числа, символы и пр.).
Если разрыв устранён, добавляем новые элементы в массив и идём дальше.
Если разрыв всё-таки есть, то пропускаем его и после вынесем в отдельный участок для модификаций.
Когда все разрывы будут обнаружены приступаем к самой мути: ищем в коде условные и безусловные переходы.
Начнём мы естест-но с таких слов, как IF ELSE REPEAT AGAIN UNLIL
После всё равно надо будет прошерстить весь код на поиск переходов. Все эти переходы вместе с метками будут занесены в массив.
Отлично, теперь у нас есть весь (или почти весь) код отражённый в массиве элементов.
К которому уже можно применять оптимизирующие правила.
Недостатки: Он тупо сложный и по этому для форта ненадёжный.
1) Попробуйте найти все переходы в нативе не прибегая к помощи дизассемблера, которого нет.
2) Что делать с компилирующими словами? Часть данных в структурах будет повторяться. Как вариант, пройтись по массиву и проверить код ещё раз на валидность.
3) Нестандартная адресация. К примеру, хранение адреса/смещения в ячейке. Как это вообще детектировать, чтобы после скорректировать?

Облегчённый вариант написанного выше.
Опять же всё суём в массив, тут же ликвидируем разрывы если есть, и при этом оптимизирующие правила применяем сразу.
Так проще и глобально мало что сломаешь. Но тоже-таки не совсем надёжно, зато приучит к хорошему программированию и простым словам :)
Сообщение Добавлено: Пн июл 15, 2019 16:31
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
Накидал где-то за час новый транслятор файлов, который при возникновении ошибки спозиционирует её с точностью до последнего отранслированного слова.
Вывод то-бишь при ошибке:
Файл в котором воникла ошибка
Номер строки, на которой произошло исключение.
Слово породившее исключение.
Ну и собственно код исключения и пояснение к нему.

Это всё сделано с участием 3 высокоуровневых библиотек, 2 из которых можно выкинуть, если заморочиться и уменьшить тем самым понятность кода.

Ложка дёгдя тоже есть.
Транслятор работает построчно, с полным текстом файла в хипе и вызовом слова SPLIT
Проще говоря медленно. Это даже может быть заметно на большой цепочке файлов.
Сообщение Добавлено: Вс июн 30, 2019 23:43
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
Ethereal писал(а):
Чтобы чикать списки не нужна их позиционная независимость. И списки могут быть сколь угодно разрывны. В чем тут проблема ?


Вот смотрите при хранении слов. структур в позиционно-независимо возникнет задача получить LFA словаря для навигации.
Если пространство непрерывно не вопрос. Адрес начала пространства + смещение до словаря. Делов-то.
А вот если при необходимости память будет выделяться и связываться в список, то фишка "адрес+смещение" не прокатит.
Ведь возникает вопрос: относительно какой части словарного пространства эта фишка должна работать. По сути надо будет организовывать поиск, чего не хочется.
Сообщение Добавлено: Сб июн 29, 2019 21:48
  Заголовок сообщения:  Re: Nova Дневник разработчика  Ответить с цитатой
Victor__v писал(а):
Думаю сделать пространство словарных структур позиционно-независимым насколько это возможно.
Это позволит убрать пространство слов. структур в случае нужды или хорошенько его почикать.
Чтобы чикать списки не нужна их позиционная независимость. И списки могут быть сколь угодно разрывны. В чем тут проблема ?
Обходишь списки и пересшиваешь их, выкидывая все элементы списков, которые не лежат в диапазоне адресов основного кодофайла программы. Словари, которые не определены в этом диапазоне чикаешь полностью из списка словарей. В итоге временные словари удалены. После забываешь про память где они лежали. Главное, чтобы код на который они ссылались остался в кодофайле.
Сообщение Добавлено: Сб июн 29, 2019 20:45

Часовой пояс: UTC + 3 часа [ Летнее время ]


cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB