Потратил пару часов на отладку и запуск Новы под 64 бита. Ссыль на рабочий образец.

В общем, перефигачивать все внутреннее устройство было крайне занимательно. И как результат система запущена, но все еще имеет много багов:
Вылетает компиляция множества слов.
Пространство данных имеет неверный указатель (видимо косякнул в ЦК).
Ломается временный словарь.
Другие скрытые от меня баги.

Буду причесывать.

Вроде все всплывшие баги починил.
В настоящее время пишу с нуля (а почему бы и да) под 64 бита некоторые полезные либы (лок. переменные, строки в хипе, поддержка плав. чисел и пр.).

Потом буду копаться с OpenGL, сделаю что-то простое и интересное.

Дальнейшее предполагаемое развитие Nova-forth:
- Возможность удалять произвольные словарные структуры (такая возможность есть и сейчас, но надо возиться ручками).
- Расширить роль инлайн-вставок.
- Причесать ядро с помощью текстового оптимизатора, чтоб было чуть быстрее и меньше занимало места
- Добавить новые слова (а то задолбало меня слово COMPARE заменю на S= )

В разных Форт системах есть некоторое количество уже сделанных примеров c OpenGL
Интересно, что интересное предполагается сделать?

P.S. К примеру, в BigForth есть пример подобия отображения диаграммы МРТ мозга в динамике, но это вроде сделано на 2D в SDL2
(там же есть Дракончик в OpenGL, а также, к примеру, уроки примеров из НеHе в gForth,Win32Forth ...)


Что мешает добавить алиас слова COMPARE в виде определения S= , если хочется и оставить совместимость с COMPARE?

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

Приведите примеры из других фортов по работе с OpenGL версии 5 и выше (компиляция шейдеров и вот это все, а не простое рисование линий). Надо ж хоть как-то идти в современность).


Почитайте стандарт (мне, например, пришлось сие слово приводить к нему, чтобы одна из СПФовских либ хотя бы начала работать). COMPARE несколько замудренное слово для специфических задач.
S= \ str1 len1 str2 len2 -- flag

И проще и наглядней.



Посмотрим.

Обычные трехмерные сцены тоже вполне полезны. Шейдеры - это отдельная технология, в целом там ничего такого волшебного нет. Но чтобы OpenGL нормально работал, надо его правильно в ядро вставить, чтобы система не стартовала с черной консоли, где надо и окно, и цикл обработки сообщений вручную. А если так, то зачем вообще Форт? Ничего в готовом виде не запущено, функции не подключены, константы не определены, а делать надо ровно то же, что на C++.

Возможная альтернатива - управление из Форта автоматом состояний, который реализован в OpenGL. Базовые возможности стартуют сразу, в приложении инициализируется сцена, может быть даже источники света в наиболее очевидных положениях (но в выключенном состоянии). У меня вот еще встроенный вызов слова 3D на отрисовку сцены. Оно интерпретируется, поэтому можно определять там что угодно, и это быстро с точки зрения правки кода. Плюс полезны были бы заготовки на уровне автовычисления нормалей, привязки текстур, создания дисплейных списков и массивов вершин. Ну и шейдеры, опять же в простом варианте подключения.

Just for fun

Не надо for fun Как фреймворк Форт восхитителен. Можно "вынести за скобки" всю рутинную работу. Только для этого нужно сразу не превращать его в "как Си, только на Форте". Тогда точно придется играть с мейнстримом на его поле и по его правилам.

Уже подумываю насчет MESH3D ( addr, xsize, ysize -- ), чтобы можно было двумерные массивы быстро показывать поверхностями. Третий раз уже приходится добавлять в код одни и те же слова по поиску диапазона и отрисовке всего сеткой.

Поскольку в Нове появилась возможность произвольно удалять словарные структуры, то существует потенциальная проблема с вызовом API-функций.

Суть проблемы:
При старте форт-система обходит все имеющиеся словарные структуры на поиск апи-функций. Если функция найдена, то она сбрасывается в состояние "неинициализирована" (назовём это так). И когда будет вызов обертки, указатель на апи-функцию будет перезаписан.
А если словарной структуры условного GetStdHandle нет, то при вызове функции где-нибудь в слове произойдет вылет. Данные-то не обновлены.

Как можно решить

1. Магическое число
Перед началом апи-функции компилируется магическое число да хоть 0x20404020. Таким образом форт-система при старте перефигачевает всю кодобазу на поиск этих меток и вызова обёртки.
Надежность не абсолютна.

2. Массив указателей на структуры API
Перебрать массив всяко быстрее.
Но где его хранить?
Можно один массив на всю форт-систему сделать.
А если апи объявят во временном словаре? Тогда в массиве поcле компиляции нового exe будут нерелевантные данные пусть и несколько другого рода.
Можно же делать отдельных массив на каждое пространство. Условно будет 2 пространства (основной код + временные словари).
Но такой завязки на словари не хочется.

3. Записываем указатели сразу же в таблицу импорта в exe-шнике
Помимо очевидной сложности и кулхацкерности при должном старании в таблице импорта может закончиться место).
А еще есть хитрые функции чья инициализация зависит от контекста (привет OpenGL!)

4. Пусть обертки сами следят за своей актуальностью.
Непонятно как сделать элегантно, т. е. без проверок во время вызова api. Вызов с участием смещения?
аля
MOV RSI, [addr]
CALL [RBX+RSI]
Но в этом случае придется каким-то образом проинициализировать ВСЕ внешние функции, чтобы подход работал. И по сути возвращаемся к тому, с чего и начали.

5. Массив структур апи-функций
Определение апи-функции будет содержать
следующий код:
...
MOV RBX, [ADDR]
LEA RBX, [RBX+API_offest]
CALL [RBX]
...

Соответственно, вся "магия" будет происходить в массиве. Там же и будет перезапись с инициализацией.


Еще варианты?

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

С одной стороны верно, но с другой стороны почему работоспособность внешних вызовов должна зависеть от словарной структуры?

Так если программист сам начинает изменять эту словарную структуру, убирая что-то из поиска, то наверное он понимает что делает?

Надеюсь)
Только по логике исключение из поиска словарной структуры не должно влиять на работоспособность кода.

Когда писал функцию для преобразования строки в число с плав. точкой обнаружил ошибку при трансляции обычных чисел. Не забыть исправить.

Также добавил простейшие функции для работы с хипом.
H.NEW
H.FREE
H.S+
H.N+
H.UN+
H.B+
H.W+
H.DW+
H.CELL+
H.FILE+


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

Все-таки возможность создавать дополнительные точки входа в функцию достаточно полезна.

Например, недавно сия возможность помогла мне расширить функциональность трансляции строк с числа с минимумом усилий.
Как так вышло
Слово STR>NUM разбирает числа со знаком и с префиксом 16-ричности. Совершенно нормально слово схавает строку "-0xAA1234", но на днях потребовалось транслировать просто числа без этих наворотов.

Путь нормального человека: написать отдельное слово для трансляции. А после сделать рефакторинг слова STR>NUM

Путь курильщика: использовать слово с наворотами, но вызывать его без определения наворотов