Forth http://www.fforum.winglion.ru/ |
|
Nova Дневник разработчика http://www.fforum.winglion.ru/viewtopic.php?f=58&t=3227 |
Страница 7 из 15 |
Автор: | 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 из 15 | Часовой пояс: UTC + 3 часа [ Летнее время ] |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |