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

Простой пример: как сделать стек? Это может быть статический массив. Или стек выделяется динамически при старте форт-системы. А размер может быть опять-таки фиксированным, или же передаваться в настройках/из внешней программы, создающей данный экземпляр форт-машины. Или стек просто передается из внешней программы. И все это (плюс фантазия) имеет право на существование. Дальше добавятся разночтения в файловых операциях, словарях, поиске и т.д.

Я не утверждаю, что это плохо. Наоборот, это следует принять как данность (иначе все разбегутся). Я бы даже сказал, эту особенность RuFIG стоит сделать ее сильной стороной! На эту тему можно еще подумать. Пока что я вижу такой принцип: следить за содержимым .h-файлов - их подключение должно быть безболезненным. Это и так рекомендуется для Си, однако стоит отдельно следить, чтобы описание какой-либо функции "не перекрывало кислород" альтернативным реализациям.

Для таких спорных моментов я бы предложил сделать так: по умолчанию любой модуль/библиотека/файл - файл. Пока реализация в одном экземпляре - это файл. Как только их становится больше одной, то делаем каталог, а в нем уже несколько разных реализаций данного модуля/библиотеки. Ну и само собой следить, чтобы у разных реализаций ключевая часть интерфейса совпадала (входные/выходные параметры и т.п.). Может даже вынести интерфейсы в отдельные файлы? Я не спец по СИ. Как это в нем обычно делается?

В Си со структурой проекта все довольно печально. Директива #include равносильна вставке всего текста включаемого файла, поэтому возможны неожиданные эффекты. Однако форт-машина особых интерфейсов-то и не имеет - это большой плюс. Поэтому при необходимости воспользоваться чьей-то реализацией можно будет просто включать соответствующий файл в свой .cpp, и оттуда уже вызывать все, что нужно. Тут есть маленькая тонкость - крайне нежелательно, чтобы в .h формировались словарные статьи. То есть они могут быть описаны, и даже описаны структуры словаря, функции для поиска слов и их добавления, но тогда их сложнее будет отменить. Лучше, чтобы конкретные настройки, в том числе и сборка рабочего словаря, делались уже в cpp, которые уже могут быть сильно индивидуализированы - кому dll, кому консоль, кому окно. Не говоря уже о том, что и подключать-настраивать они смогут все очень по-разному.

Хоршо. На гитхабе есть википедия - предлагаю описывать вот такие моменты в ней. Надо сделать какой-то отдельный раздел типа dev и там описывать инструкции как правильно вести разработку. И можно даже пару-тройку линков привести на какую-то дополнительную литературу.

Вскрылась проблема:

mingw и как выяснилось gcc, игнорируют директиву "naked" упорно вставляя пролог/эпилог в определение функции на inline asm. Из-за этого нет возможности написать базовые (hard) слова на чистом asm. Потенциально можно воспользоваться внешним ассемблером, но это связано с большими трудностями, особенно в Linux. Есть возможность конвертации строки байтов в тело функции, но для этого опять же нужен ассемблер, для получения байтов машинного кода.
Если отказаться от mingw и как следствие от gcc - то на чем писать? Чисто на ассемблере? как быть с Linux?

Какие есть предложения?

Я планирую писать на Си и использовать шитый код. Это не позволит выжать максимум производительности, но ведь Форт и так не предназначен для этого. Будем брать другим...

Я провел испытание своего форта на D в Linux. Причем удалось собрать библиотеку с фортом как в статическом варианте ( forthd.a ), так и динамическом ( forthd.so ). На статическом варианте удалось собрать программу на C++ вместе со статической линковкой. Сборка:


и с динамической:


forthd.so испытал на SP-Forth. Всё работает.

Так как генерируемый D код в бинарном представлении совместим с кодом C++ возможно смешение модулей обоих языков. D на 90% похож на C++

В связи с этим, а так же с уже имеющийся наработкой ядра, предлагаю рассмотреть вопрос о разработке проекта нового Форта на языке D.

Ну а чего мы сейчас будем скакать туда-сюда? На Qt ведь тоже есть наработки.

Ядро форта на D - это всего лишь OBJ. Включай его куда хочешь, хоть в Qt. Есть опыт работы из форта с Qt.
Само ядро очень быстрое --> подпрограммный шитый код. Ни чего не мешает изменять его, для достижения новых возможностей.

Сам D кроссплатформенный (на любой вопрос отвечают в течении 2 часов, вот пример: http://forum.dlang.org/thread/olhlvzmah ... .dlang.org ), компактный имеет очень активное сообщество, умеет делать 64 разрядные программы и имеет inline asm 64 разрядный. Освоить его - всего одна неделя, при условии знания С++. Интеграция D <---> C++ проверена и вполне функциональна.

На мой взгляд, на этой платформе ( используя опыт и имеющиеся наработки ) есть все предпосылки создать РЕАЛЬНО продвинутый вариант Форта

Извините, что прерываю столь ученых господ, но факта того, что никакие два фортера никогда не говорятся на уровне реализации (если они у них конечно есть), никто пока не отменял. Тут и спорить не о чем (поэтому не надо это замечание считать за приглашение ко флуду). Обсуждали 100500 раз и всегда с одним и тем же результатом. И никакой лепро... тьфу... репозиторий тут не поможет.

Ну мы ведь на то и делаем несколько веток. Идея была в том, чтобы забирать по мере необходимости C++. Но как вариант, можно забирать и obj. Да хоть ассемблер, в конце концов Пойдем по фактическому состоянию дел.

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

А мы же и есть в отдельном разделе. ТЗ я предлагаю тоже разделить и иметь возможность делать собственные модификации.

пардон ме, проворонил 8)


имхо, надо для начала иметь хоть какое-то, и начинать не с написания кода, а с требований к нему.