Наконец-то достигнута важная контрольная точка - запуск нового варианта Кварка. Что это и зачем?
1. MinGW + GLUT + Eclipse - подразумевается Windows + Linux.
2. typedef long long CELL; - это будет 64 бита по умолчанию, но typedef int CELL тоже регулярно проверяется.
3. Формат взаимодействия идентичен первому Кварку - программа верхнего уровня отправляет строки на интерпретацию и самостоятельно забирает образ экрана
glDrawPixels(2048, 2048, GL_RGBA, GL_UNSIGNED_BYTE, ScreenBuffer); На 4К2К потом тоже можно будет попробовать, это не проблема.
4. Приоритеты - плавающая точка и OpenGL.

Собственно, достигнутая контрольная точка - демонстрация экрана, заполненного через PIXEL и EMIT.
Программе нужно подключить единственный файл.
#include "forth.h"

И выполнить инициализацию:
Code = new char[1000000];
Data = new char[1000000];
Dstack = new CELL[1024];
Rstack = new CELL[1024];
InitVM();

Предполагаемый FAQ:
1. Где исходные тексты и где это на github?
Нигде. Проект не предполагается делать долгостроем с непонятными перспективами и перетаскиванием одеяла на себя несколькими чрезмерно активными участниками. Обсуждение и фрагменты кода на форуме - да. В конце концов, что есть наше главное достояние? Люди, а не код! И людям можно помогать продвигаться в самом методе работы и конкретных технических деталях.
2. Будет ли ANS?
Нет.
3. Но это же пиар!
Нет, это не пиар. Сейчас есть потребность в рабочем инструменте, который мог бы быть встроен в более крупные программные продукты для управления оборудованием, САПР и пакеты математического моделирования. Предыдущий Кварк для этого оказался довольно неплох, но
а) его перестают пропускать антивирусы
б) производительность оказалась не так важна (ее обеспечивал ассемблер), а вот интеграции с программой верхнего уровня маловато - хочется еще более плотного управления элементами GUI прямо из встроенного Форта
Поэтому стадия пиара остается в данном проекте далеко позади, просто за ненадобностью что-то кому-то предлагать и махать флажками перед европейцами, чтобы они заметили.

А возможность использовать dll/so и callback планируется?

Да, только тут надо еще подумать, как лучше организовать.

А будет возможность запускать Quarck на машине работающей без графики (сервер)?

Да, там есть целый набор define-ов, по наличию которых в ВМ добавляются соответствующие слова. Например, есть DISPGRAPHICS, при наличии которого вообще в принципе выделяется память под виртуальный экран и определяются такие слова, как PIXEL, EMIT на основе отрисовки символов как bitmap и прочее в таком духе. Соответственно, если это выключить, графики не будет. С текстом то же самое - за вывод текста во внутренний буфер отвечает define, да и вообще ВМ ничего самостоятельно не делает, а только предоставляет интерфейс для запуска строки на Форте и собственные внутренние ресурсы.

В качестве одной из тестовых платформ выступает Cortex-A (в составе ПЛИС Zynq-7000), там есть варианты Linux и No OS (имеется в виду "чистая" система без ОС, с набором драйверов низкого уровня).

Я заинтригован! Есть смысл поупражняется на 1-м Кварке или лучше пока подождать?

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

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

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

Как может выглядеть второй вариант. Внешняя программа создает кнопку и держит в переменных ее координаты, размеры и текст на кнопке. За всем этим она обращается к Форт-машине. Соответственно, если выполнится строка вида 10 Button1 SET-X, то при ближайшей отрисовке внешняя программа прочитает это значение и установит для кнопки соответствующую координату. Это неуниверсально, поскольку требует периодического пересмотра структуры С-части программы, однако при наличии структуры позволяет достаточно гибко все там перетасовывать. Чтобы понять, насколько это вообще удобоваримо, нужны примеры использования.

Разумно.


Малость туплю: "Форт" - это пользовательский код, а "внешняя программа" - Quark?

В данном случае Quark-Forth - это идея форт-машины, которая встраивается в какую-то другую программу. Есть quark.dll и quark.exe на его основе, который никакой особой оболочки не предоставляет, а выводит просто графическое окно с массивом пикселов. По принципу "программа на С/Lazarus вызывает dll" сделано несколько проектов, от САПР до несложных IDE. На Си написан GUI, а вот нажатие кнопок на нем приводит к вызову строк на Форте. Поэтому можно определить слова типа Run, Test, а уж потом заняться их доработкой. Перекомпиляция Си при этом не требуется, потому что программа на Си в любом случае берет некий файл на Форте (который как раз меняется и дорабатывается) и вызывает все время одни и те же слова из него.



Да, примерно так. Здесь, правда, есть небольшой непонятный момент с callback. Альтернатива, над которой я думаю, примерно такая. Все кнопки и прочие контролы создаются программой на Си (тут условно, потому что это может быть С++ или что-то еще). А вот чтобы понять, в каких координатах их надо выводить, вызывается строка из форт-машины на уровне Forth("button1 get-x"); , причем Си-функция Forth() исполняет строку и возвращает верхнее число со стека. Поэтому программа на Форте может самостоятельно перемещать кнопки, скрывать их, задавать разный текст, и заодно изменять наполнение этой кнопки - поскольку при нажатии кнопки будет вызвано не что-то откомпилированное, а что-то вроде Forth("button1 execute-action"); В итоге у нас остается один и тот же exe, но появляется возможность редактировать текстовый файл на Форте со словами типа get-x get-y execute-action для кнопок, чекбоксов и прочего.

Очень будет пользительно, если Вы прикрутите к сетевым словам и JSON. В 8th реализовано и например Телеграмм бот, реализуется весьма легко!

Урра!!!
Ilya
А JSON реализуется достаточно легко, вот тут есть отличная логическая схема: http://www.json.org/ А вот реализация объектов и структур - уже второй вопрос.

Сейчас оно принципиально запустилось на ПЛИС - Zynq7020, на подсистеме ARM. Пока ничего выдающегося, просто успешно скомпилировался forth.h.

Обнаружилось, что 64 бита не пошли - видимо, адаптированный под ARM компилятор отказался работать с long long. Однако все было предусмотрено и 32/64 регулируется одним typedef.

ух ты!!!
а там версии для тестировщиков-волонтером не предусмотрено?)

Да это надо хотя бы до вменяемого состояния довести. 64 бита не пошли, файловые операции сразу отключены. А так по-хорошему надо делать репозиторий и аккуратно там возиться.

В качестве платформы Zedboard.

А кстати, никаких IP-ядер для Zedboard не наработано? Можно было бы под них и организовать тестирование.