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

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

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

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

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

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

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

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

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

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

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

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

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

[quote="mOleg"]Для вызова кода из временных словарей используй отдельный вариант (8 байт)[/quote]

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

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

[quote="mOleg"]А вопрос был по поводу кода в хипе, ты его собираешься сохранять? Если да, то как?[/quote]
А зачем его сохранять?
Оверлеи мне особо и не пригодились.
Можно конечно заморочиться созданием релокаций, но нафига?

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

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

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

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

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

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

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

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

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

[quote="mOleg"]переходы внутри одного определения - короткие,
между определениями - длинные.
имхо[/quote]
Эм?

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

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

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

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

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

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

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

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

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

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

[code]
MOV RBX, code
CALL RBX
[/code]

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

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

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

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

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

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

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

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

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

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

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

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

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

Сложности:
Поскольку код предполагает потенциальный доступ множества потоков к одному и тому же массиву, логичным будет ввести блокировку массива потоком. Так сказать, сделать двоичный семафор.
Благо, у меня была [url=https://vk.com/@forth_programming-dvoichnyi-semafor-x86]небольшая заметка на эту тему[/url]

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

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

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

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

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

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

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

[quote]+ не тратится время на поиск одного и того же слова по несколько раз?[/quote]
Это в СПФ NOTFOUND каждый раз искался в словаре, в Nova просто прописано в поле, откуда обработчик берётся.