Forth
http://www.fforum.winglion.ru/

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

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

mOleg писал(а):
переходы внутри одного определения - короткие,
между определениями - длинные.
имхо

Эм?

"короткие" 4 байта
"длинные" 8 байт.

Речь не о том, какие переходы лучше, а как дальновиднее будет обойти ограничения архитектуры x86 касательно длин переходов

Автор:  mOleg [ Чт сен 24, 2020 10:31 ]
Заголовок сообщения:  Re: Nova Дневник разработчика

Покажи для начала программу, где длинные переходы будут оправданы.
Размер бинарника даже в гигабайт выглядит чудовищным

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

mOleg писал(а):
Покажи для начала программу, где длинные переходы будут оправданы.
Размер бинарника даже в гигабайт выглядит чудовищным


Всего 2 слова: временные словари.

Неизвестно По какому адресу ОС выделит для них память.
Ну и, естественно, может возникнуть ситуация, когда нужно создать код просто в хипе.

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

Victor__v писал(а):
временные словари

ну и вызывай их длинными переходами
кстати, а как собираешься вызывать такой код? И, главное, как его сохранять?(или не предполагается сохранять?)

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

Не понял сути вопроса.
Переведите свою мысль на язык простых смертных)

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

Для вызова кода из временных словарей используй отдельный вариант (8 байт)

А вопрос был по поводу кода в хипе, ты его собираешься сохранять? Если да, то как?

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

mOleg писал(а):
Для вызова кода из временных словарей используй отдельный вариант (8 байт)


Отдельный вариант будет использоваться, если расстояние между кодом и местом вызова больше/меньше 0x80000000

В большинстве случаев это как раз будет вызов слова из основного пространства кода во врем. словарь.

mOleg писал(а):
А вопрос был по поводу кода в хипе, ты его собираешься сохранять? Если да, то как?

А зачем его сохранять?
Оверлеи мне особо и не пригодились.
Можно конечно заморочиться созданием релокаций, но нафига?

Обычно нет необходимости сохранять временные словари) Они же временные, ака плагины для форта)

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

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

Еще не все отладил. но результат уже нравится.
Например, был убран затык с а-ля виртуальными методами. Теперь они прописываются в код инициализатора по человечески, а не квадратно-гнездовым способом.

Сделал создание кода инициализатора с 2 дополнительными точками входа. Теперь можно создать свой префикс (по умолчанию ALLOC-), или полностью свои имя для инициализации объекта.

Автор:  Victor__v [ Вт янв 12, 2021 16:25 ]
Заголовок сообщения:  Re: Nova Дневник разработчика

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

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

Но у меня возникла проблема.
Как сделать пространство словарей позиционно-независисым?

Сначала я думал полностью обойти все словарные статьи в словарях и поменять там значения LFA, NFA и LLFA.
Однако обход ненадежен. Никто не запрещает пользователю, например, создать полностью изолированный словарь, который потом можно будет перебирать.

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

Однако в словарном пространстве сохраняются имен слов.
Сначала я думал просто сохранять их после структуры, однако это усложнит использование дополнительных точек входа в код.

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

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

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

Также планирую, что вместе с 32-битной версией выйдет и 64-битная. А то давно хотел.

Автор:  Victor__v [ Чт июл 15, 2021 12:18 ]
Заголовок сообщения:  Re: Nova Дневник разработчика

Меееедленно, но верно весь код Nova-forth переписывается под 64 бита.

Примитивы написаны почти все.
Добавил новые примитивы − -! 1-! RADD
Убрал ряд маловостребованных примитивов, таких как N>KEEP, например.

Сделать отдельные пространства кода, данных словарных статей и их имен было на удивление просто.
Также было написано слово отвечающее за перевод указателей в этих пространствах в смещения и обратно.
Назвал это слово offseting aka смещатор)

Пришлось с нуля переписывать обертки под вызовы.
Пришел к такой модели:
1) Код обертки
2) указатель на код API или на инициализирующий код
3) Указатель на имя функции
4) Указатель на библиотеку функции

Соот-но шаблон обёртки:
POP RBX
...
...
...
CALL QWORD [RBX]
...
...
...
RET

Из-за особенностей fastcall в винде наплодил 5 интересных слов:
(1call) (2call) (3call) (4call) (Ncall)
Можно было бы и одним словом, но так проще на мой взгляд.

Возникла проблем из разряда слона-то я и не приметил:

Описание проблемы:
В ЦК хеши у слов будут 32-битные
А поиск в итоговой системе будет вестись по 64-битному хешу. Соот-но находить изначальные слова интерпретатор не будет.

Варианты решения:

1) Использовать в ЦК длинную арифметику.
Недостатки:
надо писать длинную арифметику, а мне лень)

2) Использовать в ЦК и в итоговой системе поиск по 32-битному хешу. Недостатки:
хеш-функцию для итоговой системы придется писать на асме;
функия всегда будет возвращать 32-битный результат.

3) Пусть сначала в итоговой будет 32-битная хеш-функция, а при последующих обновлениях (у нас уже будет 64-битная система), перейти на портируемый вариант.
Недостатки:
для первой итерации придется опять же писать на асме хеш-функцию.

4) выгрузить все имена слов в текстовый файл, а после отдать его на обработку сторонней 64-битной системе.
Недостатки:
такую систему надо найти;
при обновлении слов придется создавать весь список с хешами заново.

В общем, думаю использовать 3-й вариант.

Автор:  Hishnik [ Чт июл 15, 2021 13:18 ]
Заголовок сообщения:  Re: Nova Дневник разработчика

Victor__v писал(а):
2) Использовать в ЦК и в итоговой системе поиск по 32-битному хешу. Недостатки:
хеш-функцию для итоговой системы придется писать на асме;
функия всегда будет возвращать 32-битный результат.

А зачем тут вообще нужен хеш? Неужели предполагается использовать настолько большие тексты, что время поиска станет заметным на фоне общего времени работы программы?

Автор:  Victor__v [ Чт июл 15, 2021 14:47 ]
Заголовок сообщения:  Re: Nova Дневник разработчика

Так исторически сложилось)
К тому же сравнивать числа проще, чем строки

Автор:  Hishnik [ Чт июл 15, 2021 15:27 ]
Заголовок сообщения:  Re: Nova Дневник разработчика

Victor__v писал(а):
Так исторически сложилось)

Но оно же для чего-то сложилось. Если уже набираются проблемы, то может быть, преимущества не так уж и важны?

Victor__v писал(а):
К тому же сравнивать числа проще, чем строки

Если один раз написать функцию StringCompare, то вся сложность больше не будет видна.

Автор:  Victor__v [ Чт июл 15, 2021 15:31 ]
Заголовок сообщения:  Re: Nova Дневник разработчика

Если так уж интересно.
Я сталкивался с просадкой скорости интерпретации слов.
Сильно явно это заметно в макроподстановщике, который используется для оптимизации форт-ядра в текстовом представлении
т. е. который заменяет например ( 2 CELLS + на 8 и более замысловатые случаи).

Автор:  Hishnik [ Чт июл 15, 2021 15:42 ]
Заголовок сообщения:  Re: Nova Дневник разработчика

Я это и имею в виду. Это похоже на ситуацию, когда одна проблема исправляется не ее устранением, а добавлением другой, компенсирующей. Понятно, что хеширование ускоряет именно поиск слов, причем его определенную часть - сравнение. Если уж на то пошло, то вместо связанного списка можно рассматривать и более эффективные для поиска структуры, чтобы решить проблему кардинально. Но вопрос в том, является ли именно интерпретация текста наиболее критичной по времени операцией? Заменить 2 CELLS на 8? Можно вручную, если уж так надо поменять наглядное представление на более эффективное. Можно и [ 2 CELLS ] LITERAL написать, и будет скомпилирован литерал, вычисленный в режиме интерпретации.

Более важный вопрос другой. Чему конкретно мешает интерпретация? Там система, которая должна сверхбыстро стартовать? Или у нее постоянная работа связана с интерпретацией мегабайтов текста на Форте?

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