В ЦК был обнаружен странный баг.

Уж не знаю почему, но часть компилирующих слов по какой-то причине вообще не реагируют на изменения.

И слово REFILL (возможно не одно) по какой-то причине использует неверное смещение. При том в самом форте всё норм, но новын слова будут ссылаться не на то места.

Буду копаться или переписывать ЦК,

Выпилил очередную порцию багов у тут пришли идеи в мой мозг.

Механизм наименования ошибок.
Аля:
THROW-MES:
-2003 : WORD NOTFOUND
-2012 : FORTH TRANSLATE ERROR
not_value : IS NOT VALUE
virtual_empty : OOP: VIRTUAL FUNC NOT INIT!!!
THROW-MES;

А подробнее?....

Просто список значений.
Если код ошибки дошёл до верхнего уровня, то вместо вывода, собственно, кода будет выводиться заданная в THROW-MES: THROW-MES; строка.

Что ж, придётся признать страшную правду. В моей форт-системе много костылей и несуразностей

Сейчас думаю как избавиться от одного слова VOC>REAL

Что слово делает – превращает идентификатор словаря в реальный адрес для последующих манипуляций. Идентификатор не более чем указатель на структуру, которая содержит:
1) Указатель на переменную, где хранится адрес пространства.
2) Смешение в данном пространстве до словаря.

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

В общем, хочется и чтоб реальный адрес был и чтоб динамические пространства были, и чтоб по красоте, и никаких структур на горизонте. Где ТРИЗ когда он так нужен)

Варианты обхода проблемы, какие мне в голову пришли:

1) Храним структуру словаря в реальном пространстве
Преимущества: Простота реализации.
Недостатки: Некрасиво, словарные структуры будут выбиваться из общего ряда с другими словами. Нельзя произвольно изменять размер словарной структуры.

2) Изменяем словарь в динамическом пространстве при соответствующих событиях.
Преимущества: на самом деле сделать это не так уж и сложно
Недостатки: Код вида CURRENT @ CONSTANT test-voc будет багоопасным, что не есть хорошо. При каждом обновлении придётся перетряхивать стек контекста, переменную CURRENT. А ведь устаревшие указатели могут быть дополнительно спрятаны пользователем.

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

Может реальный адрес не обязательно должен быть реальным? Почему бы не сделать его типа "сегмент:смещение" и учесть это в словах (@ ! C@ C! и др.) работающих с памятью? Например 8 бит номер динамического пространства и 24 бит смещение (для 32-битного форта). Итого 256 пространств размером до 16Мб. Или мало?

tsdima
Да, точно с ними такая же хрень возможна.
Но если со словарём ещё можно придумать практическое применение, то вот с переменными я затрудняюсь... Ну вот кому придёт в голову сделать что-то вроде
VARIABLE TEST
TEST CONSTANT TEST2

????



Это копец как мало, что даже не смешно.

И как бы переход на реальные адреса упрощает систему. Сейчас у меня указатель на словарь как раз и предоставляет собой указатель на связку база+смещение в 16 байт. (система 64-битная).

Ну 20 бит номер, 44 бита смещение. Лям динамических куч по 16 терабайт. Хватит?

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

Ядро усложнится не немножко, а офигеть как) Работа с памятью вот просто везде.
Как работать с выделенной памятью в хипе?
Как работать с выделенной памятью в стеке?
Как модифицировать уже существующий код?
Как писать компилирующие слова (аля 0x65 c 0x48 c,)?

Ладно бы Вы предложили для работы связок база+смещение отдельный набор слов, так нет жеж) Предлагаете всё менять.

При помощи слов @ ! C@ C!


Допустим, что стек это тоже хип.


Приобрести достаточно пива для этого марафона.


А код тоже располагается в хипе? Для локальных вызовов можно использовать относительный call. А как вызываются слова из другого хипа? Адрес CFA тоже ведь указатель.


С точки зрения обычного пользователя форта, отдельный набор слов для работы связок база+смещение - это неприемлемо. Поэтому да, всё менять.

Окей, напишите реализацию слов C! C@ @ ! , которые будут работ с базой+смещение, а также одновременно с нормальными адресами. Покажите мастер-класс.

Я имел ввиду, что в стеке будут только адреса вида "база+смещение". Каждый раз перед их использованием, слова @ ! должны конвертировать их в нормальный адрес. И соответственно, например слово-переменная, помещать в стек тоже адрес вида "база+смещение". Арифметические операции над такими адресами (при условии, что база в старших битах 64-битного слова), тоже допустимы. Мы же не складываем адрес+адрес. Вычитать адреса (адрес-адрес) из разных хипов смысла не имеет.

Вообще, не видя кода, сложно давать советы. Где можно посмотреть то, что есть сейчас?

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

Моделируем ситуацию: Вот выделили в хипе условный мегабайт, а винда дала куче адрес размером под 7 байт еще и не выровненный. Как его шифровать?

Код Новы выложу позже.

Предполагается, что форт-программа не сможет оперировать реальными адресами. "Нереальный адрес" это просто число, старшие биты которого - порядковый номер кучи, младшие - смещение от начала кучи.


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

Чтобы сконвертировать в реальный адрес, отделяем номер кучи от смещения, берём адрес кучи из массива, используя номер кучи в качестве индекса, и добавляем смещение. Это низкоуровневая операция и она недоступна программам на форте, только определённое количество слов ядра, работающих с памятью, должны это делать.

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

В принципе, можно базу:смещение сделать по 32 бита, тогда проще будет отделять базу от смещения, просто грузить из стека первый или второй dword. А если нужно выделить кучу больше 4Гб то номер кучи нужно выровнять так, чтобы смещение не конфликтовало с номером (т.е. пропустить несколько элементов массива адресов до нужного номера с достаточным количеством младших нулевых бит) и заполнить элементы так, чтобы первый был реальным адресом кучи, второй = адрес+4Гб, третий +8Гб и т.д.

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

Будет полезно хранить в первых ячейках кучи такие параметры как: размер кучи, порядковый номер кучи (т.е. её виртуальный адрес), может что-то ещё.