Forth http://www.fforum.winglion.ru/ |
|
Nova Дневник разработчика http://www.fforum.winglion.ru/viewtopic.php?f=58&t=3227 |
Страница 5 из 14 |
Автор: | Ethereal [ Пн май 27, 2019 10:47 ] |
Заголовок сообщения: | Re: Nova Дневник разработчика |
Можно было бы определить наготово слово GUI и сделать два варианта сохранения - консольный S" Proga.exe" SAVE и гуевый GUI S" Proga.exe" SAVE Просто когда гуй отлаживаешь очень удобно сделать вот так ( GUI ) S" Proga.exe" SAVE и вываливать отладочную информацию в консоль. А как отладил скобки убрать и все. Я в своем Win-32 говнофорте именно так сделал. Одно из действительно удобных вещей там. P.S. Но ресурсы мой говнофорт пришпандоривает |
Автор: | Victor__v [ Ср июн 12, 2019 00:38 ] |
Заголовок сообщения: | Re: Nova Дневник разработчика |
Потихоньку причёсываю новую версию. По замечанию Ethereal решил добавить Гуй то бишь портировать winlib от ~yz. Вначале всё шло хорошо. Добавлял слова для совместимости. Пришлось тотально переписать одно слово в модуле ~yz отвечающем за подгрузку виндяшных констант. Но самый ужас меня посетил, когда я увидел в основном файле (winlib.f) слово generate-names Это слово перебирает слова внутри временного словаря и на их основе создаёт другие слова. Вот только перебор там никак не оформлен. Как же хорошо, что у меня есть итераторы Более того у ~yz несколько странное решение относительно локальных переменных. В файле они подгружаются, а в этом слове не участвуют, а оно, слово это, сложноватое. Ну я переписал его с локальными переменными. Бр-р, результат небо и земля по понятности. Однако процесс портирования у меня застопорился. Скомпилированный код отказывался искать виндяшные константы. Путём медитации нашёл виновника. Это моя реализация слова COMPARE. Это слово у меня не стандартное - тупо работает: строки равны или нет. А вот реализация ~yz по ходу-таки требовала доп. фишек оговорённых в стандарте Ну, мне не жалко. Я переписал это слово. Вот только при этом умудрился закрыть почти все портируемые файлы . Результат не заставил себя ждать У меня слова порождаемые generate-names начали компилироваться с флагами появившимися хрен его знает откуда. А их в реализации нет Завтра буду лазить по файлам ~yz искать свои косячки. Самое главное, если флаги подавить, то код работает. Только откуда эти флаги взялись блин. |
Автор: | Ethereal [ Чт июн 20, 2019 06:15 ] |
Заголовок сообщения: | Re: Nova Дневник разработчика |
Victor__v писал(а): По замечанию Ethereal решил добавить Гуй то бишь портировать winlib от ~yz. Удивительно насколько разные подходы. У меня сплошой минимализм. Я гуй прикрутил добавив в Форт только два слова. СловоКод: ; A defining word used in the form: ; KERNEL32: cccc ; Creates a word cccc, which executes cccc function of KERNEL32.DLL and ; returns the return value of this function data on stack. It there is ; no function with a given name cccc in kernel32.dll the created word ; will terminate a program. в 9 слов шитого кода и 19 команд ассемблера. И примитивное слово Код: ENTRY 3, 'GUI', GUI ; Future application created by SAVE will be GUI-application. DD $+4 mov byte [_SUBSYSTEM], 2 NEXT$ А все остальное вытягиваю за этот хвостик прямо в прикладной программе. Вот так : Через это буду тянуть : Код: KERNEL32: GetProcAddress KERNEL32: LoadLibraryA Для динамического импорта определяю два вспомогательных слова Код: : API: <BUILDS ' BYE , DOES> @ CALL ; : (API:) ( hDll pfa -- ) DUP NFA COUNT 1F AND HERE 2DUP + >R SWAP CMOVE R 1- 80 TOGGLE 0 R> C! HERE ROT GetProcAddress DUP 0= IF -1 BYE THEN SWAP CELL+ ! ; Определяю имена функций которые заимпортирую, чтобы они стали словами Форта Код: API: CreateWindowExA API: DefWindowProcA API: DispatchMessageA API: GetMessageA API: LoadCursorA API: LoadIconA API: PostQuitMessage API: RegisterClassA API: ShowWindow API: TranslateMessage API: UpdateWindow И теперь слово которым импортирую Код: : IMPORT Главное слово программы начинаю с импорта :" USER32" 1+ LoadLibraryA DUP ' CreateWindowExA (API:) DUP ' DefWindowProcA (API:) DUP ' DispatchMessageA (API:) DUP ' GetMessageA (API:) DUP ' LoadCursorA (API:) DUP ' LoadIconA (API:) DUP ' PostQuitMessage (API:) DUP ' RegisterClassA (API:) DUP ' ShowWindow (API:) DUP ' TranslateMessage (API:) ' UpdateWindow (API:) ; IMPORT Код: : MAIN IMPORT И сохраняю программу как гуевую... Код: ' MAIN CFA ' (MAIN) ! GUI SAVE .\Window.exe BYE Все примитивно просто и не скажу, что это удобно, хотя просто шапка с динамическим импортом копипастится из программы в программу и это не сложно, только список импортируемых функций поправляю. Но главное - бац, бац и готово, собрали из камней и веток и уже гуим. А у тебя другой подход - ты целую либу портируешь с какими-то временными словарями, итераторы какие-то, я так не умею. И даже не знаю что такое итераторы. Нет, определенно хочу твой Форт (после того как будет готов пример создания простейшего окна) заценить, вот как будет в сравнений твой подход с моим из камней и веток, насколько велика будет разница в удобстве программирования ? Просто удобнее или пропасть как удобнее ?P.S. Вот как в итоге после камней и веток у меня простейшее окно выглядит : Код: CALL: WndProc Т.е. поначалу камни и ветки, а в итоге все приличненько. Ну не Qt конечно, все через нативные виндозные API-функции, что словами Форта стали, но то, что надо.
( lParam wParam Msg hWnd -- ... n ) OVER CASE WM_DESTROY OF 0 PostQuitMessage ( DROP ) 0 ENDOF >R DefWindowProcA R> ENDCASE ; : MAIN IMPORT IDI_APPLICATION 0 LoadIconA WindowClass hIcon ! IDC_ARROW 0 LoadCursorA WindowClass hCursor ! WindowClass RegisterClassA DROP 0 400000 0 0 CW_USEDEFAULT DUP 2DUP WS_OVERLAPPEDWINDOW " Window Application" 1+ WindowClass lpszClassName @ 0 CreateWindowExA SW_SHOWNORMAL OVER ShowWindow DROP UpdateWindow DROP BEGIN 0 0 0 msg GetMessageA WHILE msg TranslateMessage DROP msg DispatchMessageA DROP REPEAT 0 BYE ; |
Автор: | Victor__v [ Чт июн 20, 2019 09:37 ] |
Заголовок сообщения: | Re: Nova Дневник разработчика |
У Жиловца много чего намешано в библиотеках. Навскидку треть можно выкинуть из-за ненужности в конце. Зато там нет ООП , как к примеру, в библиотеках ~nn Я пытался портировать его реализацию ООП, поверх которого есть ГУЙ, но что-то не сраслось А касательно родного ГУЯ вообще на винде. На мой взгляд это порождение Сотоны. Лучше IUP тогда использовать, там хотя бы по-человечески всё сделано. Лично мне самому разбираться с Гуем на винде не сильно улыбается |
Автор: | Hishnik [ Чт июн 20, 2019 12:52 ] |
Заголовок сообщения: | Re: Nova Дневник разработчика |
Victor__v писал(а): По замечанию Ethereal решил добавить Гуй то бишь портировать winlib от ~yz. Мне это уже довольно давно активно не нравилось, причем не в тактическом смысле, а в смысле устаревшей архитектуры. Что такое GUI в Windows, известно уже давно. С приходом Windows началось переползание с процедурного ДОС-программирования на программирование, управляемое событиями, что вызывало недовольство программистов, привыкших в ДОС управлять программой "строчками сверху вниз". Т.е. поставили INPUT - ввелось число, подставляем его в формулу, печатаем и т.д. А в Windows пришлось раскидывать функциональность по трем местам: сначала сама функция, потом надо придумать элемент управления, который будет ее вызывать и назначить ему генерируемое сообщение, а в завершение вставить в обработчик проверку на это сообщение с вызовом функции. И надо сказать, все довольно-таки рутинно, зато можно запутаться, особенно если логика программы создается и модифицируется на лету. Собственно, среда Delphi и подобные ей средства визуального проектирования и стали реакцией на эту рутину. Генерация сообщения и его обработка уже автоматизированы в движке программы, остается вписать в сгенерированный шаблон "сюда мы попадем, если нажмут вот эту кнопку" только логику. Это, наподобие динозавров, прошло свой круг эволюции, от восторгов возможностью рисования интерфейса, до некоторой усталости от "мышизма" с отловом нужных координат. Поэтому во многих книгах по визуальному программированию упоминают, что виджеты можно создавать и динамически, начиная с чистого окна программы. Собственно, если можно делать в рантайме CreateWindowEx, то можно вызывать и конструкторы виджетов с существенно более широкими функциями. В целом, имея в программе интерпретатор (и компилятор, конечно, куда же без него), можно избавиться от необходимости заранее устанавливать все возможные связи между виджетами и программными объектами (я не имею в виду чисто object, а вообще все компоненты программы, реализуемые разработчиком). На практике невозможно без отдельного, заранее добавленного виджета, установить значение переменной X. Но в Форте-то возможно! Поэтому если в GUI-программу добавляется интерпретатор, то GUI может получиться гораздо интереснее, причем без необходимости заранее перечислять все, что там может в интерфейсе произойти. Собственно, вот здесь я уже про это рассказывал. http://fforum.winglion.ru/viewtopic.php?f=23&t=3165&start=32 Код: 0 BUTTON.SHOW 100 100 75 25 0 BUTTON.RECT " +" 0 BUTTON.TEXT " +" 0 BUTTON.ACTION В движок это подцепится автоматически, без необходимости что-то делать с обработчиком. После нажатия кнопки будет выполнен текст, заданный для ACTION. В современном ПО вполне существуют аналогичные подходы, к примеру Tcl/Tk, где на Tcl можно в рантайме управлять виджетами программы. Вообще, заявляемое назначение Tcl довольно близко пересекается с сильными сторонами Форта, только Форт получается ближе к низкому уровню и потому предоставляет больше возможностей глубокой переработки архитектуры. Так что, на мой взгляд, движок WinGUI надо прятать, поскольку что-то там улучшать или модифицировать ни к чему. Повторение на Форте того, что в 90-е годы делали для С++ и Object Pascal, вообще малоперспективно - от этого будут воротить нос просто из-за крайне малой базы кода, примеров и реализованных проектов, что является неким показателем того, что основные баги отловлены и можно рассчитывать на поддержку. |
Автор: | Victor__v [ Чт июн 20, 2019 13:09 ] |
Заголовок сообщения: | Re: Nova Дневник разработчика |
Повторюсь ещё раз. Я не разбираюсь в виндяшном гуе и не хочу насиловать себе мозг им. Есть QT, GTK и пр. Лучш ими заняться, танцев с бубнами меньше. Я просто беру готовый и работающий код и пытаюсь его портировать (успех близок А вот использовать QT.DLL и иже с ними, это неспортивно |
Автор: | Hishnik [ Чт июн 20, 2019 13:18 ] |
Заголовок сообщения: | Re: Nova Дневник разработчика |
Victor__v писал(а): Я просто беру готовый и работающий код и пытаюсь его портировать (успех близок А вот использовать QT.DLL и иже с ними, это неспортивно Ну, в принципе, сформированная позиция, имеющая право на жизнь. Я-то как раз упомянул, что Форт в качестве "наездника" на Qt.dll вполне годится, но при расхождении во взглядах на этот принципиальный вопрос получаются просто независимые направления. Что в целом хорошо уже потому, что два направления больше, чем одно |
Автор: | Victor__v [ Чт июн 20, 2019 13:26 ] |
Заголовок сообщения: | Re: Nova Дневник разработчика |
QT у меня завести не получилось. Он постоянно чего-то требовал В итоге забил на него. С IUP всё пошло легче. Особенно когда нашёл примеры на кошерном Си |
Автор: | Victor__v [ Чт июн 20, 2019 17:54 ] |
Заголовок сообщения: | Re: Nova Дневник разработчика |
Распишу состояние Новы на сегодня, чтобы бiло Параметрических слов почти не осталось: Исключения: CREATE USER-CREATE ,слова-обёртки ( WINAPI Cdecl: и пр. ). Переменные и векторы больше не параметрические слова. Для доступа к данным/адресу с пом. TO или FROM на этапе компиляции/интерпретации допрашивается структура слова и выдаётся её дополнительный CFA и адрес хранения данных хранящийся там же рядом. У некоторых слов появились альтернативные режимы. Во первых, это все слова по управлению памятью DP HERE C, W, , ALLOT S, используя перед ними слово ALT: компиляция будет идти не в пространство кода, а в пространство данных. Добавив ещё один ALT: Т.е. ALT: ALT: HERE Можно манипулировать пространством словарных структур. Расположение пространств: Словарные структуры Данные Код Если пространства начинают залезать друг на друга, то слово CONTROL-CDW выделит новые участки для пространств. У каждого словаря может быть свой обработчик контроля пространств. При определении словаря внутри другого, обработчик наследуется (копируется в новый словарь). Слово CONTROL-CDW участвует в INTERPRET и SHEADER(std) Этот механизм по умолчанию не даёт 100% гарантии, что данные, код и слов. структуры не пересекутся. Поскольку он не контролирует операции, а только отслеживает изменения. Другие слова с альтернативными режимами кода: Обычные словари. К примеру, FORTH засунет себя в контекст, а ALT: FORTH положит свой LFA на стек данных. Удобно для использования словарных итераторов, да и код выглядит более эстетичней. Слова для поиска слов. SFIND SFIND-IN-VOC ' ['] вместо флагов и токена возвращают lfa слова в случае успеха. TEMP-WORDLIST при альтернативном режиме возьмёт со стека кол-во байт для выделения памяти под словарь. |
Автор: | Victor__v [ Чт июн 27, 2019 13:59 ] |
Заголовок сообщения: | Re: Nova Дневник разработчика |
Думаю сделать пространство словарных структур позиционно-независимым насколько это возможно. Это позволит убрать пространство слов. структур в случае нужды или хорошенько его почикать. Для этого нужно, чтобы все хранящиеся указатели там (кроме CFA) превратились в смещения до требуемых данных То бишь поля NFA LFA LLFA должны хранить смещения. Возникающие проблемы. Что делась со словарями? В данный момент LFA словаря компилируется напрямую. Однако приоритет сменяется на поиск нужного LFA Самый простой вариант в данном случае это взять адрес начала пространства слов. структур и скомпилировать смещение до LFA. Однако есть тут ложка дёгтя. Пространства могут разрываться. К примеру, если памяти не хватает и нужно выделить новую участок. Варианты: 1) забить болт и сделать пространство слов. структур непрерывным, выделив ему память в куче. Сложности: 1.1 временные словари. придётся специально для них заморичиться и написать FREE-WORDLIST (сейчас делается FREE THROW ), который будет учитывать дополнительное наличие памяти для слов. структур, которую надо будет удалить. 2) Сделать список словарных пространств. В этом случае обнаружение и компиляция LFA словаря потребует поиска в реальном времени, ибо смещения до словарей будут по сути ненадёжны. Общая сложность. Где разместить это словарное пространство, учитывая что его можно будет безболезненно удалить? Логично, что в конце пространства кода, а при старте форт-системы перенести её куда-нибудь и переписать указатель. Что-то вроде: Код: HERE CELL+ HERE @ \ указатель на пространство и его размер, записанные в конце пространства данных
DUP ALLOCATE THROW >R R@ SWAP MOVE R> CURRENT @ L>wordFA @ ! |
Автор: | Ethereal [ Сб июн 29, 2019 20:45 ] |
Заголовок сообщения: | Re: Nova Дневник разработчика |
Victor__v писал(а): Думаю сделать пространство словарных структур позиционно-независимым насколько это возможно. Чтобы чикать списки не нужна их позиционная независимость. И списки могут быть сколь угодно разрывны. В чем тут проблема ?Это позволит убрать пространство слов. структур в случае нужды или хорошенько его почикать. Обходишь списки и пересшиваешь их, выкидывая все элементы списков, которые не лежат в диапазоне адресов основного кодофайла программы. Словари, которые не определены в этом диапазоне чикаешь полностью из списка словарей. В итоге временные словари удалены. После забываешь про память где они лежали. Главное, чтобы код на который они ссылались остался в кодофайле. |
Автор: | Victor__v [ Сб июн 29, 2019 21:48 ] |
Заголовок сообщения: | Re: Nova Дневник разработчика |
Ethereal писал(а): Чтобы чикать списки не нужна их позиционная независимость. И списки могут быть сколь угодно разрывны. В чем тут проблема ? Вот смотрите при хранении слов. структур в позиционно-независимо возникнет задача получить LFA словаря для навигации. Если пространство непрерывно не вопрос. Адрес начала пространства + смещение до словаря. Делов-то. А вот если при необходимости память будет выделяться и связываться в список, то фишка "адрес+смещение" не прокатит. Ведь возникает вопрос: относительно какой части словарного пространства эта фишка должна работать. По сути надо будет организовывать поиск, чего не хочется. |
Автор: | Victor__v [ Вс июн 30, 2019 23:43 ] |
Заголовок сообщения: | Re: Nova Дневник разработчика |
Накидал где-то за час новый транслятор файлов, который при возникновении ошибки спозиционирует её с точностью до последнего отранслированного слова. Вывод то-бишь при ошибке: Файл в котором воникла ошибка Номер строки, на которой произошло исключение. Слово породившее исключение. Ну и собственно код исключения и пояснение к нему. Это всё сделано с участием 3 высокоуровневых библиотек, 2 из которых можно выкинуть, если заморочиться и уменьшить тем самым понятность кода. Ложка дёгдя тоже есть. Транслятор работает построчно, с полным текстом файла в хипе и вызовом слова SPLIT Проще говоря медленно. Это даже может быть заметно на большой цепочке файлов. |
Автор: | Victor__v [ Пн июл 15, 2019 16:31 ] |
Заголовок сообщения: | Re: Nova Дневник разработчика |
Очередной виток идей для улучшения форта, поскольку реальной задачи у меня всё равно нет 1) Промежуточная стадия компиляции. Т. е. код компилируется не в натив, а в энн-ый набор структур, к которым уже применяются оптимизирующие правила. Недостаток не предусматривает расширяемости. Если кому-то придёт в голову использовать в определении ассемблерные ставки, то они могут после тупо затереться. Также нужно приложить сильное колдунство, чтобы учитывались компилирующие эффекты некоторых слов. 1.1) Очередной вариант оптимизатора. Ну вот люблю я их делать а после выкидывать на помойку) Алгоритм: Отслеживаем каждое слово, записываем все данные о нём в массив структур и компилируем/исполняем его. И так всё вплоть до слова ; Это слово по сути является спусковым крючком. Далее просматриваем весь массив элементов и ищем разрывы в коде между элементами. Так мы попробуем определить не-слова (числа, символы и пр.). Если разрыв устранён, добавляем новые элементы в массив и идём дальше. Если разрыв всё-таки есть, то пропускаем его и после вынесем в отдельный участок для модификаций. Когда все разрывы будут обнаружены приступаем к самой мути: ищем в коде условные и безусловные переходы. Начнём мы естест-но с таких слов, как IF ELSE REPEAT AGAIN UNLIL После всё равно надо будет прошерстить весь код на поиск переходов. Все эти переходы вместе с метками будут занесены в массив. Отлично, теперь у нас есть весь (или почти весь) код отражённый в массиве элементов. К которому уже можно применять оптимизирующие правила. Недостатки: Он тупо сложный и по этому для форта ненадёжный. 1) Попробуйте найти все переходы в нативе не прибегая к помощи дизассемблера, которого нет. 2) Что делать с компилирующими словами? Часть данных в структурах будет повторяться. Как вариант, пройтись по массиву и проверить код ещё раз на валидность. 3) Нестандартная адресация. К примеру, хранение адреса/смещения в ячейке. Как это вообще детектировать, чтобы после скорректировать? Облегчённый вариант написанного выше. Опять же всё суём в массив, тут же ликвидируем разрывы если есть, и при этом оптимизирующие правила применяем сразу. Так проще и глобально мало что сломаешь. Но тоже-таки не совсем надёжно, зато приучит к хорошему программированию и простым словам |
Автор: | Victor__v [ Вт окт 01, 2019 14:40 ] |
Заголовок сообщения: | Re: Nova Дневник разработчика |
Всё-таки пора переходить на 64 бита. А то у нас тут на форуме их нема. Только Кварк Хищника. Мало товарисчи, мало Основной затык как и прежде: большая архитектурно-зависимая часть. Меньший затык: Надо написать обёртку на fastcall в винде. Сейчас добавил в форт слова DW@ DW! DW, От слов @ ! , сейчас ничем не отличаются. 32-бит всё-таки. Просто задел на будущее. Ввёл слово SSET-OUT т. е. убрать элемент из множества на стеке. С такой операцией гораздо проще писать самоудаляторы библиотек. |
Страница 5 из 14 | Часовой пояс: UTC + 3 часа [ Летнее время ] |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |