Автор |
Сообщение |
|
|
Заголовок сообщения: |
Re: OpenForth: структура файлов |
|
|
Hishnik писал(а): А мы же и есть в отдельном разделе. пардон ме, проворонил 8) Hishnik писал(а): ТЗ я предлагаю тоже разделить и иметь возможность делать собственные модификации. имхо, надо для начала иметь хоть какое-то, и начинать не с написания кода, а с требований к нему.
[quote="Hishnik"]А мы же и есть в отдельном разделе. [/quote] пардон ме, проворонил 8)
[quote="Hishnik"]ТЗ я предлагаю тоже разделить и иметь возможность делать собственные модификации.[/quote] имхо, надо для начала иметь хоть какое-то, и начинать не с написания кода, а с требований к нему.
|
|
|
|
Добавлено: Ср июн 24, 2015 15:58 |
|
|
|
|
|
Заголовок сообщения: |
Re: OpenForth: структура файлов |
|
|
mOleg писал(а): Предлагаю на форуме завести отдельный раздел для обсуждения сабжа, во-первых, и, во-вторых, таки надо набросать ТЗ. А мы же и есть в отдельном разделе. ТЗ я предлагаю тоже разделить и иметь возможность делать собственные модификации.
[quote="mOleg"]Предлагаю на форуме завести отдельный раздел для обсуждения сабжа, во-первых, и, во-вторых, таки надо набросать ТЗ.[/quote] А мы же и есть в отдельном разделе. ТЗ я предлагаю тоже разделить и иметь возможность делать собственные модификации.
|
|
|
|
Добавлено: Ср июн 24, 2015 15:49 |
|
|
|
|
|
Заголовок сообщения: |
Re: OpenForth: структура файлов |
|
|
Предлагаю на форуме завести отдельный раздел для обсуждения сабжа, во-первых, и, во-вторых, таки надо набросать ТЗ.
Предлагаю на форуме завести отдельный раздел для обсуждения сабжа, во-первых, и, во-вторых, таки надо набросать ТЗ.
|
|
|
|
Добавлено: Ср июн 24, 2015 15:42 |
|
|
|
|
|
Заголовок сообщения: |
Re: OpenForth: структура файлов |
|
|
mgw писал(а): На мой взгляд, на этой платформе ( используя опыт и имеющиеся наработки ) есть все предпосылки создать РЕАЛЬНО продвинутый вариант Форта Ну мы ведь на то и делаем несколько веток. Идея была в том, чтобы забирать по мере необходимости C++. Но как вариант, можно забирать и obj. Да хоть ассемблер, в конце концов Пойдем по фактическому состоянию дел.
[quote="mgw"]На мой взгляд, на этой платформе ( используя опыт и имеющиеся наработки ) есть все предпосылки создать РЕАЛЬНО продвинутый вариант Форта[/quote] Ну мы ведь на то и делаем несколько веток. Идея была в том, чтобы забирать по мере необходимости C++. Но как вариант, можно забирать и obj. Да хоть ассемблер, в конце концов :) Пойдем по фактическому состоянию дел.
|
|
|
|
Добавлено: Пн июн 22, 2015 13:09 |
|
|
|
|
|
Заголовок сообщения: |
Re: OpenForth: структура файлов |
|
|
mgw писал(а): На мой взгляд Извините, что прерываю столь ученых господ, но факта того, что никакие два фортера никогда не говорятся на уровне реализации (если они у них конечно есть), никто пока не отменял. Тут и спорить не о чем (поэтому не надо это замечание считать за приглашение ко флуду). Обсуждали 100500 раз и всегда с одним и тем же результатом. И никакой лепро... тьфу... репозиторий тут не поможет.
[quote="mgw"]На мой взгляд[/quote]Извините, что прерываю столь ученых господ, но факта того, что никакие два фортера никогда не говорятся на уровне реализации (если они у них конечно есть), никто пока не отменял. Тут и спорить не о чем (поэтому не надо это замечание считать за приглашение ко флуду). Обсуждали 100500 раз и всегда с одним и тем же результатом. И никакой лепро... тьфу... репозиторий тут не поможет.
|
|
|
|
Добавлено: Пн июн 22, 2015 10:48 |
|
|
|
|
|
Заголовок сообщения: |
Re: OpenForth: структура файлов |
|
|
Ядро форта на D - это всего лишь OBJ. Включай его куда хочешь, хоть в Qt. Есть опыт работы из форта с Qt. Само ядро очень быстрое --> подпрограммный шитый код. Ни чего не мешает изменять его, для достижения новых возможностей. Сам D кроссплатформенный (на любой вопрос отвечают в течении 2 часов, вот пример: http://forum.dlang.org/thread/olhlvzmah ... .dlang.org ), компактный имеет очень активное сообщество, умеет делать 64 разрядные программы и имеет inline asm 64 разрядный. Освоить его - всего одна неделя, при условии знания С++. Интеграция D <---> C++ проверена и вполне функциональна. На мой взгляд, на этой платформе ( используя опыт и имеющиеся наработки ) есть все предпосылки создать РЕАЛЬНО продвинутый вариант Форта
Ядро форта на D - это всего лишь OBJ. Включай его куда хочешь, хоть в Qt. Есть опыт работы из форта с Qt. Само ядро очень быстрое --> подпрограммный шитый код. Ни чего не мешает изменять его, для достижения новых возможностей.
Сам D кроссплатформенный (на любой вопрос отвечают в течении 2 часов, вот пример: http://forum.dlang.org/thread/olhlvzmahkahstsujpph@forum.dlang.org ), компактный имеет очень активное сообщество, умеет делать 64 разрядные программы и имеет inline asm 64 разрядный. Освоить его - всего одна неделя, при условии знания С++. Интеграция D <---> C++ проверена и вполне функциональна.
На мой взгляд, на этой платформе ( используя опыт и имеющиеся наработки ) есть все предпосылки создать РЕАЛЬНО продвинутый вариант Форта
|
|
|
|
Добавлено: Пн июн 22, 2015 10:42 |
|
|
|
|
|
Заголовок сообщения: |
Re: OpenForth: структура файлов |
|
|
Ну а чего мы сейчас будем скакать туда-сюда? На Qt ведь тоже есть наработки.
Ну а чего мы сейчас будем скакать туда-сюда? На Qt ведь тоже есть наработки.
|
|
|
|
Добавлено: Пн июн 22, 2015 00:01 |
|
|
|
|
|
Заголовок сообщения: |
Re: OpenForth: структура файлов |
|
|
Я провел испытание своего форта на D в Linux. Причем удалось собрать библиотеку с фортом как в статическом варианте ( forthd.a ), так и динамическом ( forthd.so ). На статическом варианте удалось собрать программу на C++ вместе со статической линковкой. Сборка: Код: dmd -c forthd.d gcc main.cpp forthd.o libphobos2.a -lpthread -o mainTestFort
и с динамической: Код: dmd -c forthd.d dmd -c forth.d dmd -shared -offorthd.so forthd.o forth.o -defaultlib=libphobos2.so
# Программа проверки gcc -omainf2 mainf2.c -ldl
forthd.so испытал на SP-Forth. Всё работает. Так как генерируемый D код в бинарном представлении совместим с кодом C++ возможно смешение модулей обоих языков. D на 90% похож на C++ В связи с этим, а так же с уже имеющийся наработкой ядра, предлагаю рассмотреть вопрос о разработке проекта нового Форта на языке D.
Я провел испытание своего форта на D в Linux. Причем удалось собрать библиотеку с фортом как в статическом варианте ( forthd.a ), так и динамическом ( forthd.so ). На статическом варианте удалось собрать программу на C++ вместе со статической линковкой. Сборка: [code] dmd -c forthd.d gcc main.cpp forthd.o libphobos2.a -lpthread -o mainTestFort [/code]
и с динамической: [code] dmd -c forthd.d dmd -c forth.d dmd -shared -offorthd.so forthd.o forth.o -defaultlib=libphobos2.so
# Программа проверки gcc -omainf2 mainf2.c -ldl [/code]
forthd.so испытал на SP-Forth. Всё работает.
Так как генерируемый D код в бинарном представлении совместим с кодом C++ возможно смешение модулей обоих языков. D на 90% похож на C++
В связи с этим, а так же с уже имеющийся наработкой ядра, предлагаю рассмотреть вопрос о разработке проекта нового Форта на языке D.
|
|
|
|
Добавлено: Вс июн 21, 2015 23:14 |
|
|
|
|
|
Заголовок сообщения: |
Re: OpenForth: структура файлов |
|
|
mgw писал(а): Если отказаться от mingw и как следствие от gcc - то на чем писать? Чисто на ассемблере? как быть с Linux?
Какие есть предложения? Я планирую писать на Си и использовать шитый код. Это не позволит выжать максимум производительности, но ведь Форт и так не предназначен для этого. Будем брать другим...
[quote="mgw"]Если отказаться от mingw и как следствие от gcc - то на чем писать? Чисто на ассемблере? как быть с Linux?
Какие есть предложения?[/quote] Я планирую писать на Си и использовать шитый код. Это не позволит выжать максимум производительности, но ведь Форт и так не предназначен для этого. Будем брать другим...
|
|
|
|
Добавлено: Вс июн 21, 2015 22:33 |
|
|
|
|
|
Заголовок сообщения: |
Re: OpenForth: структура файлов |
|
|
Вскрылась проблема:
mingw и как выяснилось gcc, игнорируют директиву "naked" упорно вставляя пролог/эпилог в определение функции на inline asm. Из-за этого нет возможности написать базовые (hard) слова на чистом asm. Потенциально можно воспользоваться внешним ассемблером, но это связано с большими трудностями, особенно в Linux. Есть возможность конвертации строки байтов в тело функции, но для этого опять же нужен ассемблер, для получения байтов машинного кода. Если отказаться от mingw и как следствие от gcc - то на чем писать? Чисто на ассемблере? как быть с Linux?
Какие есть предложения?
Вскрылась проблема:
mingw и как выяснилось gcc, игнорируют директиву "naked" упорно вставляя пролог/эпилог в определение функции на inline asm. Из-за этого нет возможности написать базовые (hard) слова на чистом asm. Потенциально можно воспользоваться внешним ассемблером, но это связано с большими трудностями, особенно в Linux. Есть возможность конвертации строки байтов в тело функции, но для этого опять же нужен ассемблер, для получения байтов машинного кода. Если отказаться от mingw и как следствие от gcc - то на чем писать? Чисто на ассемблере? как быть с Linux?
Какие есть предложения?
|
|
|
|
Добавлено: Вс июн 21, 2015 20:16 |
|
|
|
|
|
Заголовок сообщения: |
Re: OpenForth: структура файлов |
|
|
Хоршо. На гитхабе есть википедия - предлагаю описывать вот такие моменты в ней. Надо сделать какой-то отдельный раздел типа dev и там описывать инструкции как правильно вести разработку. И можно даже пару-тройку линков привести на какую-то дополнительную литературу.
Хоршо. На гитхабе есть википедия - предлагаю описывать вот такие моменты в ней. Надо сделать какой-то отдельный раздел типа dev и там описывать инструкции как правильно вести разработку. И можно даже пару-тройку линков привести на какую-то дополнительную литературу.
|
|
|
|
Добавлено: Вс июн 21, 2015 09:40 |
|
|
|
|
|
Заголовок сообщения: |
Re: OpenForth: структура файлов |
|
|
В Си со структурой проекта все довольно печально. Директива #include равносильна вставке всего текста включаемого файла, поэтому возможны неожиданные эффекты. Однако форт-машина особых интерфейсов-то и не имеет - это большой плюс. Поэтому при необходимости воспользоваться чьей-то реализацией можно будет просто включать соответствующий файл в свой .cpp, и оттуда уже вызывать все, что нужно. Тут есть маленькая тонкость - крайне нежелательно, чтобы в .h формировались словарные статьи. То есть они могут быть описаны, и даже описаны структуры словаря, функции для поиска слов и их добавления, но тогда их сложнее будет отменить. Лучше, чтобы конкретные настройки, в том числе и сборка рабочего словаря, делались уже в cpp, которые уже могут быть сильно индивидуализированы - кому dll, кому консоль, кому окно. Не говоря уже о том, что и подключать-настраивать они смогут все очень по-разному.
В Си со структурой проекта все довольно печально. Директива #include равносильна вставке всего текста включаемого файла, поэтому возможны неожиданные эффекты. Однако форт-машина особых интерфейсов-то и не имеет - это большой плюс. Поэтому при необходимости воспользоваться чьей-то реализацией можно будет просто включать соответствующий файл в свой .cpp, и оттуда уже вызывать все, что нужно. Тут есть маленькая тонкость - крайне нежелательно, чтобы в .h формировались словарные статьи. То есть они могут быть описаны, и даже описаны структуры словаря, функции для поиска слов и их добавления, но тогда их сложнее будет отменить. Лучше, чтобы конкретные настройки, в том числе и сборка рабочего словаря, делались уже в cpp, которые уже могут быть сильно индивидуализированы - кому dll, кому консоль, кому окно. Не говоря уже о том, что и подключать-настраивать они смогут все очень по-разному.
|
|
|
|
Добавлено: Вс июн 21, 2015 01:54 |
|
|
|
|
|
Заголовок сообщения: |
Re: OpenForth: структура файлов |
|
|
Для таких спорных моментов я бы предложил сделать так: по умолчанию любой модуль/библиотека/файл - файл. Пока реализация в одном экземпляре - это файл. Как только их становится больше одной, то делаем каталог, а в нем уже несколько разных реализаций данного модуля/библиотеки. Ну и само собой следить, чтобы у разных реализаций ключевая часть интерфейса совпадала (входные/выходные параметры и т.п.). Может даже вынести интерфейсы в отдельные файлы? Я не спец по СИ. Как это в нем обычно делается?
Для таких спорных моментов я бы предложил сделать так: по умолчанию любой модуль/библиотека/файл - файл. Пока реализация в одном экземпляре - это файл. Как только их становится больше одной, то делаем каталог, а в нем уже несколько разных реализаций данного модуля/библиотеки. Ну и само собой следить, чтобы у разных реализаций ключевая часть интерфейса совпадала (входные/выходные параметры и т.п.). Может даже вынести интерфейсы в отдельные файлы? Я не спец по СИ. Как это в нем обычно делается?
|
|
|
|
Добавлено: Вс июн 21, 2015 01:38 |
|
|
|
|
|
Заголовок сообщения: |
OpenForth: структура файлов |
|
|
Теперь надо определиться с еще одной важной проблемой - где что лежит. А главное - как организовать работу так, чтобы могли совместно существовать разные реализации отдельных задач (и их комбинации). Простой пример: как сделать стек? Это может быть статический массив. Или стек выделяется динамически при старте форт-системы. А размер может быть опять-таки фиксированным, или же передаваться в настройках/из внешней программы, создающей данный экземпляр форт-машины. Или стек просто передается из внешней программы. И все это (плюс фантазия) имеет право на существование. Дальше добавятся разночтения в файловых операциях, словарях, поиске и т.д. Я не утверждаю, что это плохо. Наоборот, это следует принять как данность (иначе все разбегутся). Я бы даже сказал, эту особенность RuFIG стоит сделать ее сильной стороной! На эту тему можно еще подумать. Пока что я вижу такой принцип: следить за содержимым .h-файлов - их подключение должно быть безболезненным. Это и так рекомендуется для Си, однако стоит отдельно следить, чтобы описание какой-либо функции "не перекрывало кислород" альтернативным реализациям.
Теперь надо определиться с еще одной важной проблемой - где что лежит. А главное - как организовать работу так, чтобы могли совместно существовать разные реализации отдельных задач (и их комбинации).
Простой пример: как сделать стек? Это может быть статический массив. Или стек выделяется динамически при старте форт-системы. А размер может быть опять-таки фиксированным, или же передаваться в настройках/из внешней программы, создающей данный экземпляр форт-машины. Или стек просто передается из внешней программы. И все это (плюс фантазия) имеет право на существование. Дальше добавятся разночтения в файловых операциях, словарях, поиске и т.д.
Я не утверждаю, что это плохо. Наоборот, это следует принять как данность (иначе все разбегутся). Я бы даже сказал, эту особенность RuFIG стоит сделать ее сильной стороной! :) На эту тему можно еще подумать. Пока что я вижу такой принцип: следить за содержимым .h-файлов - их подключение должно быть безболезненным. Это и так рекомендуется для Си, однако стоит отдельно следить, чтобы описание какой-либо функции "не перекрывало кислород" альтернативным реализациям.
|
|
|
|
Добавлено: Вс июн 21, 2015 01:18 |
|
|
|
|