Forth http://fforum.winglion.ru/ |
|
Quark C64 http://fforum.winglion.ru/viewtopic.php?f=23&t=3165 |
Страница 2 из 4 |
Автор: | diver [ Пн апр 23, 2018 10:28 ] |
Заголовок сообщения: | Re: Quark C64 |
Hishnik писал(а): А кстати, никаких IP-ядер для Zedboard не наработано? Можно было бы под них и организовать тестирование. вот чего нет, того есть) |
Автор: | Hishnik [ Сб ноя 10, 2018 22:22 ] |
Заголовок сообщения: | Re: Quark C64 |
Вот такой код успешно выполнился на Quark-C64. Ну, уже основные интересные моменты решены... Код: : R 42 EMIT2 ;
R CR : PIFAFOR 10 0 DO 10 0 DO I J * . LOOP CR LOOP ; CR : SINUS 1000 0 DO I 500 I S>F PI F* 90.0 F/ FSIN 100.0 F* F>S - 0x00FFFF PIXEL LOOP ; VOCABULARY ASSEMBLER ASSEMBLER DEFINITIONS 65536 CONSTANT MAXCODE 1024 CONSTANT MAXDATA CREATE CODE[] MAXCODE ALLOT CREATE DATA[] MAXDATA CELLS ALLOT QUAN CODE^ 0 TO CODE^ QUAN DATA^ 0 TO DATA^ QUAN CODE-START 0 TO CODE-START QUAN DATA-START 0 TO DATA-START : VIEW-CODE 256 0 DO I 16 MOD 0 = IF 0 I 16 / 3 + GOTOXY I CODE-START + . THEN I 16 MOD 4 * 8 + I 16 / 3 + GOTOXY CODE[] I + C@ . LOOP ; : VIEW-DATA 256 0 DO I 16 MOD 0 = IF 0 I 16 / 3 + GOTOXY I DATA-START + . THEN I 16 MOD 4 * 8 + I 16 / 3 + GOTOXY DATA[] I + @ . LOOP ; |
Автор: | diver [ Вс ноя 11, 2018 10:43 ] |
Заголовок сообщения: | Re: Quark C64 |
ждём официального релиза....) |
Автор: | Hishnik [ Вс ноя 11, 2018 23:28 ] |
Заголовок сообщения: | Re: Quark C64 |
Нет бы создать проект на гитхабе, взять за основу шаблон с объявлениями функций и сделать. А так у меня даже никаких иллюзий на тему возможного развития - исходники тут же начнут дергать в разные стороны, делая "быстрее", "надежнее", и "ANS-совместимее", теряя при этом заложенную архитектуру. В итоге так все и похоронится. |
Автор: | diver [ Пн ноя 12, 2018 04:09 ] |
Заголовок сообщения: | Re: Quark C64 |
Hishnik писал(а): Нет бы создать проект на гитхабе, взять за основу шаблон с объявлениями функций и сделать. А так у меня даже никаких иллюзий на тему возможного развития - исходники тут же начнут дергать в разные стороны, делая "быстрее", "надежнее", и "ANS-совместимее", теряя при этом заложенную архитектуру. В итоге так все и похоронится. Я неприхотлив, хватит и EXEшника ))) |
Автор: | Victor__v [ Пн ноя 12, 2018 11:31 ] |
Заголовок сообщения: | Re: Quark C64 |
Hishnik писал(а): Нет бы создать проект на гитхабе, взять за основу шаблон с объявлениями функций и сделать. А так у меня даже никаких иллюзий на тему возможного развития - исходники тут же начнут дергать в разные стороны, делая "быстрее", "надежнее", и "ANS-совместимее", теряя при этом заложенную архитектуру. В итоге так все и похоронится. Зачем гитхаб? Hg |
Автор: | Hishnik [ Вс янв 20, 2019 16:03 ] |
Заголовок сообщения: | Re: Quark C64 |
Код: void MainWindow::Execute(const char * s) { strncpy(Tib, s, MAXNAMELEN - 1); EvaluateTib(); } void MainWindow::Run(const char * s) { strncpy(Tib, s, MAXNAMELEN - 1); QFuture<void> f1 = QtConcurrent::run(EvaluateTib); } То есть оно вызывается и как функция, и как поток. Но вот незадача. Как из Форта получать информацию о виджетах? Можно в рантайме управлять кнопками: Код: void MainWindow::ButtonShow(int index) { if ((index >= 0) && (index < MAXBUTTONS)) { FButton[index]->show(); } } Только передать эту функцию в Форт нельзя - MainWindow должен быть экземпляром. А если Форт накидает своих действий по виджетам, то в EvaluateTib надо ждать, пока выполнится все, а в потоке немного сомнительно. Неужели пускать еще один поток и в нем смотреть, что записал в параметры виджетов поток Форта? |
Автор: | zma [ Сб фев 09, 2019 16:30 ] |
Заголовок сообщения: | Re: Quark C64 |
Hishnik писал(а): Код: void MainWindow::ButtonShow(int index) { if ((index >= 0) && (index < MAXBUTTONS)) { FButton[index]->show(); } } Только передать эту функцию в Форт нельзя - MainWindow должен быть экземпляром. Судя по тому, что нагуглилось, можно вызвать метод класса, имея указатель на метод и указатель на экземпляр класса: Код: A a;
void (A::*pf)(); // указатель на метод в классе A, который ничего не возвращает, и ничего не принимает pf = &A::f; // указатель на метод f в классе A A *pA; pA = &a; (pA ->*pf)(); // вызов метода класса A через указатель на объект класса и указатель на метод класса |
Автор: | Hishnik [ Вс фев 10, 2019 00:28 ] |
Заголовок сообщения: | Re: Quark C64 |
Код: void (MainWindow::*pf)(); pf = &MainWindow::ForthButtonShow; AddWord("BUTTON", (CELL)&((this->*pf)())); E:\XSoft\Neutron\mainwindow.cpp:54: ошибка: lvalue required as unary '&' operand AddWord("BUTTON", (CELL)&((this->*pf)())); ^ Увы, не хочет. Тут AddWord принимает слово и адрес функции. С void(), не входящими в классы, это работает. AddWord("DUP", (CELL)&ForthDup); Но вполне вероятно, что я просто хочу странного. |
Автор: | zma [ Вс фев 10, 2019 02:07 ] |
Заголовок сообщения: | Re: Quark C64 |
При таком объявлении pf надо-таки Код: AddWord("BUTTON", (CELL)pf); Остаётся открытым вопрос, как передать ещё и указатель на класс. Наверное, проще всего обернуть нужные методы из MainWindow в простые функции и обращаться к ним через экземпляр MainWindow в глобальной переменной: Код: MainWindow mainwindow;
void mwForthButtonShow() { mainwindow.ForthButtonShow(); } ... AddWord("BUTTON", (CELL)&mwForthButtonShow); |
Автор: | Hishnik [ Вс фев 10, 2019 02:16 ] |
Заголовок сообщения: | Re: Quark C64 |
Тогда получается так: E:\XSoft\Neutron\mainwindow.cpp:54: ошибка: invalid cast from type 'void (MainWindow::*)()' to type 'CELL {aka long long int}' AddWord("BUTTON", (CELL)pf); ^~ zma писал(а): Остаётся открытым вопрос, как передать ещё и указатель на класс. Наверное, проще всего обернуть нужные методы из MainWindow в простые функции и обращаться к ним через экземпляр MainWindow в глобальной переменной: Да, вот и получается интересный вопрос для раздумий. Qt делает так: Код: int main(int argc, char *argv[]) { QApplication a(argc, argv); MainWindow w; w.show(); return a.exec(); } При этом MainWindow - это тип, и в процессе описания у него нет адресов функций. Ощущение, что без существенного слома шаблонов Qt не получится сделать так, чтобы в процессе описания класса можно было его же будущие адреса передать форт-машине. А ломать не хочется из-за того, что возможные применения должны укладываться в общую логику, и не требовать изменять архитектуру приложения специально под Форт. |
Автор: | zma [ Вс фев 10, 2019 16:23 ] |
Заголовок сообщения: | Re: Quark C64 |
Эти архитектуры (Форт с последовательным выполнением и Qt с работой по событиям) в любом случае придётся как-то согласовывать. Кстати, для кросплатформенного GUI есть библиотека IUP. Написана на C (без плюсов) и работает с ним же. Поддержка OpenGL тоже есть. |
Автор: | Hishnik [ Вс фев 10, 2019 23:40 ] |
Заголовок сообщения: | Re: Quark C64 |
IUP тоже интересная (судя по галерее). Еще был VxWidgets, но у меня почему-то не собрался. В принципе, подобные вещи вполне ценны самим фактом существования, и если туда будет подключаться Форт, это дополнительный плюс. Сейчас тот вариант, который я пишу, не то чтобы жестко привязан к Qt. До этого консоль + OpenGL завелось на Eclipse + mingw и варианте gcc для ARM в ПЛИС Zynq-7000. То есть плюс в виде "форт-машина собирается с разными вариантами Си" имеет место, и я бы хотел его сохранить. Думаю, это вообще интересный вариант, если форт-машину можно будет подключать к Си-проектам просто "на всякий случай" без существенного вмешательства в их архитектуру. Для Qt я, конечно, в основном экспериментирую. Строки из Си уже вполне передаются в форт-машину, выполняются там, результаты можно забирать (все объекты форт-машины в области видимости проекта и можно смотреть стек, память, программу и т.д.). То, что я хочу сделать, уже несколько за этими пределами. Управление виджетами из форт-машины как таковое уже работает, потому что можно опрашивать все из Qt и устанавливать свойства виджетов по состоянию переменных, заданных форт-машиной. Это как раз не проблема. Проблема заключается в том, что если установка переменных производится отдельными строчками, результат виден на экране сразу. А вот если Evaluate запускает не "показать кнопку", а "запустить программу", то все изменения будут отражены после завершения Evaluate, т.е. результат будет только после отработки всего кода на Форте. Если это что-то вроде RUN, запускающего длительный расчет, то ни progress bar, ни возможности отмены, ни обновления графиков в реальном времени не будет. Пока тут несколько вариантов. 1. Кардинальный - "не выбрасывать ручечку" (с) Задорнов. Строки передаются в интерпретирующем режиме, тогда после каждой строки можно будет обновить GUI. Но это крайне неудобно, к тому же возникает проблема с загрузкой файлов - это же одна команда, которая загружает строки сама. Вобщем, вариант слишком уж компромиссный. 2. Форт-машина получает методы GUI в виде своих слов. То, что, собственно, не получается, потому что экземпляра MainWindow еще нет, и требуется "позиционная война" с компилятором, чтобы заставить его после создания главного окна найти адреса его методов и передать их форт-машине в виде CELL. И в перспективе придется еще организовать прокачку сообщений. 3. То, что чуть отложено, поскольку кажется некрасивым. Вызывающая система дублирует Evaluate и самостоятельно организует обработку строк, пользуясь при необходимости функциями форт-машины. При этом такое MainWindow::Evaluate будет уже методом главного окна, со всеми вытекающими возможностями доступа к своим виджетам. Получится некоторое дублирование функций (что и вызывает эстетическое недовольство), к тому же придется обеспечивать отдельную обработку слов, управляющих виджетами. Возможно, вплоть до хранения их списка в вызывающей программе, со специальными признаками, обеспечивающими обработку сообщений, если уж изменен виджет. Видимо, и многопоточность здесь уже не так принципиальна. |
Автор: | zma [ Вт фев 12, 2019 01:11 ] |
Заголовок сообщения: | Re: Quark C64 |
Hishnik писал(а): Если это что-то вроде RUN, запускающего длительный расчет, то ни progress bar, ни возможности отмены, ни обновления графиков в реальном времени не будет. Видел в разных библиотеках варианты с прерыванием работы. Вызовом функции библиотеки запускается некоторый длительный процесс, но он прерывается после некоторого количества определённых шагов (в случае с Фортом, например, это могут быть циклы работы адресного интерпретатора). В основную программу возвращается флаг - завершился ли процесс. Программа может выполнить какие-то свои действия и возобновить процесс вызовом отдельной функции (или той же со специальным параметром). Придётся немного изменить порядок внутренней работы. Не знаю, стоит ли оно того... Hishnik писал(а): исходники тут же начнут дергать в разные стороны, делая "быстрее", "надежнее", и "ANS-совместимее", теряя при этом заложенную архитектуру Надеюсь, я не этим сейчас занимаюсь (хоть и без исходников) |
Автор: | Hishnik [ Вт фев 12, 2019 02:07 ] |
Заголовок сообщения: | Re: Quark C64 |
zma писал(а): Видел в разных библиотеках варианты с прерыванием работы. Вызовом функции библиотеки запускается некоторый длительный процесс, но он прерывается после некоторого количества определённых шагов (в случае с Фортом, например, это могут быть циклы работы адресного интерпретатора). В основную программу возвращается флаг - завершился ли процесс. Программа может выполнить какие-то свои действия и возобновить процесс вызовом отдельной функции (или той же со специальным параметром). Придётся немного изменить порядок внутренней работы. Не знаю, стоит ли оно того... Да, это получается вариант п.3 - продублировать адресный интерпретатор еще и в методе класса MainWindow. Собственно, это просто copy-paste, но вроде бы должно сработать. zma писал(а): Надеюсь, я не этим сейчас занимаюсь (хоть и без исходников) Именно что наоборот! В истории форума (да и su.forth в FIDO) было несколько длительных дискуссий на тему "давайте откроем все исходники Фортов, чтобы сообщество их развивало". С учетом сложившихся тенденций я был тактически против, поскольку все это явно приводило к ситуации "возьмем что есть и доведем до ANS-совместимости или еще какой-либо совместимости, не интересуясь архитектурой и не пытаясь проектировать транслятор под особенности задач". Поэтому мне кажется, что любые обсуждения архитектур полезны, а тиражирование репозиториев с кусками форт-трансляторов без пояснения идей, компромиссов и возможных вариантов ведет только к генерации информационного шума и ничего по сути не дает. Фортов полно, но что-то их никто не доводит до состояния "опять появился новый полезный Форт, который многим понравился". К сожалению, я пока прогнозирую единственное видимое следствие из публикации текстов - появление очередной волны "о, здорово!... а может, все-таки сделаем из этого ANS и еще раз сходим на поклон куда-нибудь?". |
Страница 2 из 4 | Часовой пояс: UTC + 3 часа [ Летнее время ] |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |