Forth http://fforum.winglion.ru/ |
|
Forth на ... Это реально? - Попутное голосование http://fforum.winglion.ru/viewtopic.php?f=2&t=3047 |
Страница 1 из 2 |
Автор: | gudleifr [ Пт май 15, 2015 12:45 ] |
Заголовок сообщения: | Forth на ... Это реально? - Попутное голосование |
Допустим, мы имеем две "регистрово-емкие" программы, одна из которых FORTH. Например, Win-API требует сохранения регистров BP, BX, DI, SI, а FORTH, обычно, BP, BX, SI... И мы хотим как-то их совместить. Как это выгоднее сделать? 1. Пишем все на FORTH, а вызов ф-ий другой системы обвешиваем "сохранятелями регистров". 2. Пишем наш FORTH целиком на языке той системы (например, на D), заменяя регистры переменными. 3. Встраиваем в систему отдельные замкнутые FORTH-модули. 4. Проводим исследование "Кто главнее?" P.S. Сам выбрал (1) из соображений минимализма. |
Автор: | Ethereal [ Пт май 15, 2015 18:08 ] |
Заголовок сообщения: | Re: Forth на ... Это реально? - Попутное голосование |
gudleifr писал(а): Например, Win-API требует сохранения регистров BP, BX, DI, SI, а FORTH, обычно, BP, BX, SI... Наоборот. Функции Win-API, когда ты их вызываешь, сохраняют регистры BX SI DI BP, а остальные портят. Так-что ничего совмещать не надо. Все для тебя наготово уже совмещено.И мы хотим как-то их совместить. Как это выгоднее сделать? Проблема возникает только тогда, когда из Win-API вызывается CALL-back функция. И ты ее сделал на Форте. Тогда да, обвешать ее сохранятелями регистров. PUSH на входе в нее и POP на выходе. |
Автор: | gudleifr [ Пт май 15, 2015 18:14 ] |
Заголовок сообщения: | Re: Forth на ... Это реально? - Попутное голосование |
Ethereal писал(а): Наоборот. Функции Win-API, когда ты их вызываешь, сохраняют регистры BX SI DI BP, а остальные портят. Да. Имелась в виду именно работа внутри ф-ии обработки сообщений (или других call-back-ов). В них нужно вернуть эти 4 регистра винде ровно в том виде, в котором получил. Именно поэтому "обычные win-ф-ии" их и сохраняют. Более того, т.к. обработка win-сообщений часто выполняется рекурсивно, FORTH должен сохранять свои регистры в специальном стеке.Впрочем, не суть, главное, что "согласование" необходимо. |
Автор: | Ethereal [ Пт май 15, 2015 18:16 ] |
Заголовок сообщения: | Re: Forth на ... Это реально? - Попутное голосование |
Так функция обработки сообщений одна единственная. На входе в нее PUSH-и, перед выходом POP-ы. И флаг направления D нужно вернуть из нее нулевым. CLD перед выходом, если ты его портил. |
Автор: | gudleifr [ Пт май 15, 2015 18:18 ] |
Заголовок сообщения: | Re: Forth на ... Это реально? - Попутное голосование |
Ethereal писал(а): Так функция обработки сообщений одна единственная. Вообще-то, у каждого окна - своя. Кончайте флудить, лучше проголосуйте.
|
Автор: | Ethereal [ Пт май 15, 2015 18:35 ] |
Заголовок сообщения: | Re: Forth на ... Это реально? - Попутное голосование |
Ничего я не флужу. Просто ни проблемы не вижу в упор, ни сколь нибудь внятно описанной разницы между пунктами голосования. Что за исследование "Кто главнее" ? Что такое замкнутые Форт-модули ? А вариант на D не насыплет в код push и pop от души, например, директива CALLBACK и означает, что надо насыпать ? |
Автор: | gudleifr [ Пт май 15, 2015 18:58 ] |
Заголовок сообщения: | Re: Forth на ... Это реально? - Попутное голосование |
Ethereal писал(а): Ничего я не флужу. Просто ни проблемы не вижу в упор... Пардон, мне показалось, что у Вас просто приступ "блогородного негодования при виде столь поверхностного понимания". Проблему Вы сами описали: написав свой FORTH "в кодах", я должен предпринять некоторые меры по его вписыванию "в систему" (не портить чужие регистры, сохранять свои и т.д., и т.п.). Например, в том же Win-API, я вынужден буду отказаться от использования "в лоб" редакторов Win-ресурсов, т.к. FORTH "хочет" создавать ресурсы "на лету". То, что "это просто", значения не имеет. Все равно, приходится "согласовывать" и "изобретать велосипеды". Это все (1).(2) - это написание FORTH полностью на "языке системы" (на том же D). Мы делаем все оконно-зависимое на "родном языке" (руками авторов какого-либо Qt), а FORTH-машину "эмулируем": FORTH-регистры - переменные, стеки - массивы, слова - ф-ии, шитый код - массив указателей на ф-ии. (3) - это тот путь, которым пошел коллега mgw - вставкой FORTH в программу в виде кодовых фрагментов (по сути, это (1) наоборот). (4) - это невозможность предпочесть что-то из (1-3) из голого "больше нравится" и/или "более по-FORTH-овски". Мол, когда такая задача встанет, тогда и думать будем. |
Автор: | Hishnik [ Пт май 15, 2015 19:07 ] |
Заголовок сообщения: | Re: Forth на ... Это реально? - Попутное голосование |
(4) - это ответ на вопрос: "у нас две коробки, зеленая и красная, какую в какую будем вставлять?". Ответ - ту, которая меньше, в ту, которая больше. |
Автор: | gudleifr [ Пт май 15, 2015 19:14 ] |
Заголовок сообщения: | Re: Forth на ... Это реально? - Попутное голосование |
Hishnik писал(а): Ответ - ту, которая меньше, в ту, которая больше. Ну, все-таки, и FORTH, и большинство систем, с которыми, мы его пытаемся обычно "срастить" - не совсем "черные ящики". Да и личные предпочтения на основе опыта должны были бы сформироваться.
|
Автор: | Hishnik [ Пт май 15, 2015 19:24 ] |
Заголовок сообщения: | Re: Forth на ... Это реально? - Попутное голосование |
gudleifr писал(а): Ну, все-таки, и FORTH, и большинство систем, с которыми, мы его пытаемся обычно "срастить" - не совсем "черные ящики". Оно обоими способами и сращивается. Если большой системе нужна консоль/скриптовое управление, на ЯВУ пишется форт-машина и вставляется как статически скомпилированный модуль или dll, как удобнее. Если приложению, исходно написанному на Форте, требуется много стандартных функций, хорошо проработанных в других языках, оформляются фрагменты push-call-pop. |
Автор: | Ethereal [ Пт май 15, 2015 19:42 ] |
Заголовок сообщения: | Re: Forth на ... Это реально? - Попутное голосование |
gudleifr писал(а): Пардон, мне показалось, что у Вас просто приступ "блогородного негодования при виде столь поверхностного понимания". Нет. Просто Вы в фразе ""Пишем все на FORTH, а вызов ф-ий другой системы обвешиваем "сохранятелями регистров"" неудачно связали "сохранятели регистров" как-бы с вызовом функций Win-API из Форта, т.е. как раз с тем случаем когда эти "сохранятели" толком и не требуются.
|
Автор: | gudleifr [ Сб май 16, 2015 01:58 ] |
Заголовок сообщения: | Re: Forth на ... Это реально? - Попутное голосование |
Ethereal писал(а): эти "сохранятели" толком и не требуются. Требуются, требуются... Назовем состояния регистров, соответственно для FORTH и Винды - F и W. Допустим, мы вызываем из FORTH ф-ию Win-API. И до и после запуска имеем F. Но нас это не устраивает по следующим причинам - ф-я Win-API может породить вызов оконной ф-ии, куда придет со значениями W. Надо откуда-то восстанавливать F. Более того, при возвращении оттуда возможно придется F модифицировать (например увеличить регистр HERE).Но, повторю, сложность/простота этого процесса к теме относится очень опосредованно. |
Автор: | mgw [ Сб май 16, 2015 07:11 ] |
Заголовок сообщения: | Re: Forth на ... Это реально? - Попутное голосование |
Hishnik писал(а): Оно обоими способами и сращивается. Если большой системе нужна консоль/скриптовое управление, на ЯВУ пишется форт-машина и вставляется как статически скомпилированный модуль или dll, как удобнее. Если приложению, исходно написанному на Форте, требуется много стандартных функций, хорошо проработанных в других языках, оформляются фрагменты push-call-pop. Я выбрал 3 - по голосованию, или по Hishnik: на ЯВУ + inline ASM пишется форт-машина и вставляется как статически скомпилированный модуль. Думаю, что это компромисс между сложностью реализации самой форт системы и скоростью работы получившийся форт системы. Совершенно согласен с gudleifr, нужен отдельный стек возвратов для F, но я его пока не задействовал. Если я правильно понял, то в ядре SPF-Fork уже есть все механизмы для создания отдельного стека для F. Без него не реализовать рекурсию типа D --> F --> D --> F (и т.д.) А "сохранятели регистров" нужны в любом случае перехода D <--> F другое дело мы их писали явно или они уже встроены неявно, о чем и писал Ethereal. |
Автор: | Ethereal [ Пт июн 05, 2015 19:22 ] |
Заголовок сообщения: | Re: Forth на ... Это реально? - Попутное голосование |
В этом топике было сказано много слов. По моему лучше на практике попробовать есть ли какие проблемы, чем решать проблему еще не попробовав ее на вкус. Я попробовал тут к своему дурацкому Фиг-форту прикрутить оконные и диалоговые функции и очень изящно все получилось. Ввел определяющее слово CALL: для определения оконных функций так ( синтаксис FASM ) : Код: ENTRY 5, 'CALL:', CALL_COLON ; A defining word used in the form: ; CALL: cccc ... ; ; Creates a word cccc, which code field is an entry point of a window or ; a dialog procedure defined as an usual colon definition with parameters ; ( lParam wParam Msg hWnd -- ... n ) , where the top stack value on exit ; n will be returned from the procedure in eax register and the other ; stack values will be discarded. The temporal return stack with 40h ; cells depth is provided for an execution of cccc. DD DoCOLON DD COLON ; CALL: определяем через : ;Align here in aligned model DD LIT, 0E8h, HERE, CELL, MINUS_, C_STORE DD ONE, ALLOT, LIT, DoWndProc_in, HERE DD MINUS_, HERE, CELL, MINUS_, STORE_ DD SEMI_S ;Слово ;S - это EXIT Фиг-форта DoWndProc_in: pop eax push ebx push esi push edi push ebp push DoWndProc_out mov ebp, esp sub esp, 100h ;40h cells on return stack mov esi, eax push dword [ebp+36] ;lParam push dword [ebp+32] ;wParam push dword [ebp+28] ;Msg mov ebx, [ebp+24] ;hWnd NEXT$ DoWndProc_out: DD $+4 DD $+4 mov eax, ebx leave pop edi pop esi pop ebx ret 10h После чего простейшая оконная функция оказалась такой : Код: CALL: WndProc ( lParam wParam Msg hWnd -- ... n ) OVER CASE WM_DESTROY OF 0 PostQuitMessage 0 ENDOF >R DefWindowProcA R> ENDCASE ; И это все. Идея здесь такая. После определения WndProc перед ее косвенным шитым кодом оказывается call DoWndProc_in. Этот call и есть точка входа которую вызываеют Винды. call переправляет управление на DoWndProc_in с адресом начала шитого кода на стеке. Я снимаю адрес шитого кода в eax. Потом сохраняю в стек ebx esi edi. Потом опускаю esp вниз на 100h байт - это 100h байт резервируются для стека возвратов на 64 возврата. Причем на стек возвратов уже положен адрес DoWndProc_out. Ниже стека возвратов остается стек данных. Я кладу на него параметры lParam wParam Msg hWnd после чего копирую esi<-eax адрес начала шитого кода оконной фунции и по NEXT начинаю его интерпретацию. NEXT тут Код: MACRO NEXT$ { lodsd jmp dword [eax] } Когда шитокодное определение оконной функции завершается, управление улетает на DoWndProc_out. Этот код слово с вершины стека (я вершину стека в Фиг-форте храню в ebx) пихает в eax - это будет код возврата из оконной фунции. Далее из ebp восстанавливает esp и весь хлам со стека улетает. Далее восстанавливает со стека ebp edi esi ebx и завершает оконную функцию по ret 10h. Все просто и не встретилось никаких проблем с чем-либо вообще. P.S. Указатель стека данных в моем Фиг-форте - это esp. Указатель стека возвратов - ebp. Вершина стека данных в регистре ebx, остальное содержимое стека данных в аппаратном стеке esp. |
Автор: | gudleifr [ Пт июн 05, 2015 19:42 ] |
Заголовок сообщения: | Re: Forth на ... Это реально? - Попутное голосование |
Ethereal писал(а): ... Честно говоря, понять, что Вы сделали труднее, чем написать самому. Еще труднее понять, зачем Вы это сделали. Чтобы показать, что "сохранятели регистров" просты? А кто говорил, что они сложны?
|
Страница 1 из 2 | Часовой пояс: UTC + 3 часа [ Летнее время ] |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |