Опять же по поводу 0 1, если сделать, чтобы для часто используемых чисел в коде вместо lit число было call, то, вероятно, вся форт-система очень сильно похудеет (например, моя тестовая худеет очень сильно), так что если минимизация размера - самоцель, то вполне можно заняться... Можно сделать 0 constant 0 1 constant 1 2 constant 2 и т.д. и посмотреть... Если я правильно путаю, во многих реализациях делают 0 1 2 3 отдельными словами...

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



Слово ALL-WORDS-ITER: используется для инициализации api, если что

забавно, у меня так:

Все-таки ваше форматирование текста исходников я плохо воспринимаю 8(

Тут, как говорится, хозяин барин.

Нагляднее и проще, имхо, когда код для действия над каждым элементом идёт после итератора, а не играть в калбеки, понимаешь)

Код инициализации, пример как счас:

Неа, это, таки Форт: сначала параметры, потом действие 8)

Вот как в 64-битной версии будет выглядеть инициализация (по сути сброс) внешних функций.

А теперь к возникшим проблемам. Все они, что неудивительно, связаны с раздельных хранением данных.

1) Некорректные имена
Если во время изменения размера пространства под имена слов, указатель на сие пространство сместился, то словарном пространстве у нас будут некорректные указатели. В общем привет кракозябры, а то и вылет.
Варианты решения
а) хранить в словарном пространстве, не указатели на имена, а смещения. Из-за этого немного усложнится печать и пр. вывод имен слов. Некритично, но все равно неприятно. К тому же мы просто перенесём сложность из одного места в другое.
б) хранить имена прямо в словарном пространстве. Решение курильщика.
в) при каждом таком изменении указателя обновлять все словарное пространство и перезаписывать там указатели на имена

2) Сломанные словарные указатели
Опять жеж, если изменится указатель на словарное пространство, то все цепочки поиска будут некорректны. А если еще кто-то связал цепочки поиска между разными пространствами...
Варианты решения.
а) Обновление всех цепочек в слов. пространстве. Реализуемо, но лень.
б) Полный пересмотр системы поиска слов. Если есть пространство и известен размер структуры слова, то их можно просто перебирать от начала и до конца. Поскольку система поиска меняется с односвязного списка на массив, то возникают доп. проблемы: как разграничивать словари? тормоза (4 списка меняем на один массив же).
в) Все LFA будут содержать не указатели, а смещения.

Короче, лучше обновить цепочки и не выпендриваться.

3) Когда обновлять размеры?

В текущем варианте, форт-система проверяет заполненность пространств при каждом шаге интерпретации.
По сути это доп. тормоза и не дает гарантии. Да, блин, слово может просто компилировать в другом пространстве, которое не обязано совпадать с CURRENT.

В общем, логичнее всего проверять и обновлять пространства при вызове соот. слов ( , allot dw, w, c, s, и пр.)

Вести с полей.

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

Последние 2 часа анализировал скомпилированный образ в IDA
Заметил и исправил пару мелких проблем (например, забыл в компилирующем примитиве LIT, префикс 64-ой операции).

Примерный объем рабочего кода 64-битной версии составит 50 кб.
В 32-битной (ЦК) размер 37 кб (правда, тут текстовый оптимизатор постарался).
После успешного старта подключим и к 64-битке текстовый оптимизатор для сжатия всяких там банальностей.

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

Продолжаю исследовать скомпилированный образ на предмет косяков.
Косяки были найдены и ликвидированы.

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

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

Как будет выглядеть самый БЫСТРЫЙ вариант разложить 64 бита на байты?
Как получить область памяти в 8 гег для массива? (всего 16 гег)
И записать/прочитать это всё БЫСТРО в файл. (созданный массив)

А смысл давать ссылку на то, что еще не готово?
Я могу скинуть все свои наработки, без вопросов. Но там будет только исходный код 64-битного форта. Образ еще исследуется.



Это что и к чему это?
1) на ассемблере
2) использовать 8 1024 1024 1024 * * * ALLOCATE
3) В винде есть специфические функции для работы с файлами и пр., копайте туда.

Одним словом - ещё не готово...
Бум сидеть на 32-х битах.

У Хищника, вроде, Кварк на 64 бита уже есть)
Спросите, если срочно нужен.

Хм. Спасибо. Посмотрю на Quark C64.

Посмотрел. 2020 год...

Хищник, зачем спрятал от народа 64 бита?

А чего его прятать? Он методика, а не программка для скачивания.