Автор |
Сообщение |
|
|
Заголовок сообщения: |
Re: Forth на ... Это реально? - Попутное голосование |
|
|
Ethereal писал(а): Так идея то оценивается только после взгляда на реализацию. Дык, сами писали про "одно телодвижение". Я рассчитывал на то, что большинство ответивших понимает, о чем идет речь. Ethereal писал(а): WIN-RET ; мне у Вас не понравилось. Да, можно засунуть ее вызов в стек возвратов, как у Вас. Сейчас я склонен "вторичную FORTH-машину, разбирающую WIN-сообщения" еще более логически обособить. Ethereal писал(а): Жаль, что определения слова RECEPTING что-то не видно. Оно в http://localhost/g9/g2asm.txt, там же используется в NUMBER и для разбора командной строки. Описано в [url]http://localhost/cgi-bin/pilo.cgi?FL=../WWW/g9.txt&IS=\5.FOBOS[/url], параграф "ОБ ОБРАБОТЧИКАХ СООБЩЕНИЙ".
[quote="Ethereal"]Так идея то оценивается только после взгляда на реализацию. [/quote]Дык, сами писали про "одно телодвижение". Я рассчитывал на то, что большинство ответивших понимает, о чем идет речь. [quote="Ethereal"]WIN-RET ; мне у Вас не понравилось.[/quote]Да, можно засунуть ее вызов в стек возвратов, как у Вас. Сейчас я склонен "вторичную FORTH-машину, разбирающую WIN-сообщения" еще более логически обособить. [quote="Ethereal"]Жаль, что определения слова RECEPTING что-то не видно.[/quote]Оно в [url]http://localhost/g9/g2asm.txt[/url], там же используется в NUMBER и для разбора командной строки. Описано в [url]http://localhost/cgi-bin/pilo.cgi?FL=../WWW/g9.txt&IS=\5.FOBOS[/url], параграф "ОБ ОБРАБОТЧИКАХ СООБЩЕНИЙ".
|
|
|
|
Добавлено: Сб июн 06, 2015 15:44 |
|
|
|
|
|
Заголовок сообщения: |
Re: Forth на ... Это реально? - Попутное голосование |
|
|
А, кажется нашел где это все лежит.
А, кажется нашел где это все лежит.
|
|
|
|
Добавлено: Сб июн 06, 2015 15:37 |
|
|
|
|
|
Заголовок сообщения: |
Re: Forth на ... Это реально? - Попутное голосование |
|
|
gudleifr писал(а): Думаю, Вам тоже проще было написать самому, чем разобраться ... Проще указать на общую идею Так идея то оценивается только после взгляда на реализацию. Потому-что на словах идея может выглядеть и замечательно. А на практике реализовываться так коряво, что ясно, что она была неудачной. WIN-RET ; мне у Вас не понравилось. Я сделал выход из оконной функции по ; как и у любого определения не создавая лишних сущностей и слов. Только одно определяющее слово для оконных функций и все. А вот идея разбора сообщений конечным автоматом заинтриговала. Что-то в этом чувствуется могучее. Буду сейчас мучить мозг как она работает. Надо именно понять чужую мысль. Не всегда собственные мысли лучше. Жаль, что определения слова RECEPTING что-то не видно.
[quote="gudleifr"]Думаю, Вам тоже проще было написать самому, чем разобраться ... Проще указать на общую идею[/quote]Так идея то оценивается только после взгляда на реализацию. Потому-что на словах идея может выглядеть и замечательно. А на практике реализовываться так коряво, что ясно, что она была неудачной.
WIN-RET ; мне у Вас не понравилось. Я сделал выход из оконной функции по ; как и у любого определения не создавая лишних сущностей и слов. Только одно определяющее слово для оконных функций и все. А вот идея разбора сообщений конечным автоматом заинтриговала. Что-то в этом чувствуется могучее. Буду сейчас мучить мозг как она работает. Надо именно понять чужую мысль. Не всегда собственные мысли лучше. Жаль, что определения слова RECEPTING что-то не видно.
|
|
|
|
Добавлено: Сб июн 06, 2015 15:29 |
|
|
|
|
|
Заголовок сообщения: |
Re: Forth на ... Это реально? - Попутное голосование |
|
|
Ethereal писал(а): Так покажите как Вы написали сами. Хочу взглянуть... Дык, оно уже пять лет лежит все там же: http://www.gudleifr.h1.ru/g9/g2.txt, как часть FOBOS ([url]http://www.gudleifr.h1.ru/cgi-bin/pilo.cgi?FL=../g9.txt&IS=\5.FOBOS[/url]). Там было так (ассемблер мой, он описан в начале упомянутого файла): Цитата: ( ПРОСТОЕ СЛОВО ДЛЯ ВЫЗОВА ПРОЦЕДУРЫ - CALL . НЕ НАДО ЗАБЫВАТЬ, ЧТО: 1. ПОЧТИ ВСЕ ФУНКЦИИ WINDOWS СТРОЯТСЯ ПО ОБРАЗЦУ PASCAL - ПАРАМЕТРЫ ИЗ СТЕКА УДАЛЯЕТ САМА ФУНКЦИЯ; 2. СООТНЕСЕНИЕ ПЕРЕЧИСЛЕНИЯ ПАРАМЕТРОВ В СТРОКЕ C И ПОСЛЕДОВАТЕЛЬНОСТИ КОМАНД PUSH АССЕМБЛЕРА: СЛЕВА-НАПРАВО - СНИЗУ-ВВЕРХ. 3. ВЫЗОВ МНОГИХ Ф-ИЙ ПРИВОДИТ К ВЫЗОВУ ОКОННОЙ ПРОЦЕДУРЫ ) VARIABLE EDI-OLD ( ТЕКУЩАЯ ВЕРШИНА СЛОВАРЯ, КОТОРУЮ Ф-ИЯ МОЖЕТ ИЗМЕНИТЬ) VARIABLE EBP-OLD VARIABLE EBP-OLD2 ( ВЕРШИНА СТЕКА ВОЗВРАТОВ, КОТОРУЮ Ф-ИЯ ИЗМЕНИТЬ НЕ МОЖЕТ) CODE CALL ( ..., a -- w) /WO MOV, BP [DW] EBP-OLD , /WO MOV, DI [DW] EDI-OLD , CALLEW, B [RG] /DW MOV, B A [RG] /DW MOV, DI [DW] EDI-OLD , NEXT, END-CODE
...
\ БУФЕРА ДЛЯ ХРАНЕНИЯ MD-ЕРУНДЫ 64K ALLOCATE DROP CONSTANT WIN-STACK ( ДЛЯ ХРАНЕНИЯ КАДРОВ СТЕКА CALL-BACK-ОВ) VARIABLE WIN-SP WIN-STACK WIN-SP ! CREATE MSG 28 ALLOT
\ ОБРАМЛЕНИЕ ОКОННОЙ ПРОЦЕДУРЫ VARIABLE (GETMESSAGE) USER32 Z" GetMessageA" (FUNCTION) (GETMESSAGE) ! VARIABLE (TRANSLATEMESSAGE) USER32 Z" TranslateMessage" (FUNCTION) (TRANSLATEMESSAGE) ! VARIABLE (DISPATCHMESSAGE) USER32 Z" DispatchMessageA" (FUNCTION) (DISPATCHMESSAGE) ! ( САМОЕ ТОНКОЕ МЕСТО - СОХРАНЕНИЕ РЕГИСТРОВ и ВОССТАНОВЛЕНИЕ SI, DI, BP И BX, ИСПОЛЬЗУЕМЫХ MUST DIE ВНУТРИ СЕБЯ) CODE WIN-CYCLE ( -- w) ( БУДЕТ И ДРУГОЙ ВАРИАНТ - ДЛЯ ИЗВРАЩЕННЫХ ДИАЛОГОВ) /WO MOV, DI [DW] EDI-OLD , /WO MOV, BP [DW] EBP-OLD , 1 =H /DW XOR, A A [RG] A PUSHR, A PUSHR, A PUSHR, PUSHW, MSG , CALLEW, [DW] (GETMESSAGE) , /DW OR, A A [RG] ?ZR J, 2 =F PUSHW, MSG , CALLEW, [DW] (TRANSLATEMESSAGE) , PUSHW, MSG , CALLEW, [DW] (DISPATCHMESSAGE) , JMPSHORT, 1 =B 2 =H B PUSHR, /DW MOV, B [DW] MSG 8 + , /DW MOV, DI [DW] EDI-OLD , NEXT, END-CODE BEGIN-LOAD ASSEMBLER HEX : CALL-BACK CODE ( КОНЕЧНО НЕ ДЛЯ ВСЕХ CALL-BACK-ОВ, А ТОЛЬКО ДЛЯ ОКОННЫХ) /WO MOVA, WIN-SP , /WO MOV, DI A [8] 10 C, /WO MOV, SI A [8] 14 C, /WO MOV, B A [8] 18 C, /WO MOV, BP A [8] 1C C, C POPR, POPM, A [0] POPM, A [8] 4 C, POPM, A [8] 8 C, POPM, A [8] 0C C, C PUSHR, /SW ADDD, A [RG] 20 C, /DW MOVA, WIN-SP , /DW MOV, DI [DW] EDI-OLD , /DW MOV, BP [DW] EBP-OLD , SI MOVRDW, >MARK NEXT, >RESOLVE END-LOAD ] ; END-LOAD : WIN-H WIN-SP @ 32 - @ ; ( СООБЩЕНИЕ, СОХРАНЕННОЕ В КАДРЕ СТЕКА) : WIN-MSG WIN-SP @ 28 - @ ; : WIN-W WIN-SP @ 24 - @ ; : WIN-L WIN-SP @ 20 - @ ; CODE WIN-RET /WO MOV, BP [DW] EBP-OLD , A POPR, B PUSHR, ( ВОЗВРАТ ИЗ CALL-BACK) /WO MOV, DI [DW] EDI-OLD , /WO MOVA, WIN-SP , /SW SUBD, A [RG] 20 C, /DW MOV, DI A [8] 10 C, /DW MOV, SI A [8] 14 C, /DW MOV, B A [8] 18 C, /DW MOV, BP A [8] 1C C, /DW MOVA, WIN-SP , A POPR, RET, END-CODE
\ ОКОННАЯ ПРОЦЕДУРА USER32 WIN-FUNC" DEFWINDOWPROC DefWindowProcA" USER32 WIN-FUNC" POSTQUITMESSAGE PostQuitMessage" 2 CONSTANT WM_DESTROY : RECEPTOR ( <word> ... <;> w, wa, wa --) CREATE ROT , SWAP , , ] ; \ ПОЗДНЕЕ СВЯЗЫВАНИЕ РЕЦЕПТОРОВ : RECEPTOR+ ( брат, узел --) 4 + ! ; DOER !DESTROY : SUBRECEPTOR+ ( сын, узел --) 8 + ! ; ( ПОСЛЕДНИЕ В СПИСКЕ ПРОВЕРЯЕМЫХ СООБЩЕНИЙ - WIN-DESTROY И WIN-DEFAULT) 0 0 0 RECEPTOR WIN-DEFAULT WIN-L WIN-W WIN-MSG WIN-H DEFWINDOWPROC CALL ; WM_DESTROY WIN-DEFAULT 0 RECEPTOR WIN-DESTROY !DESTROY 0 POSTQUITMESSAGE CALL DROP 0 ; VARIABLE WIN ( ПЕРЕМЕННАЯ СОДЕРЖАЩАЯ АДРЕС КОРНЯ ДЕРЕВА РАЗБОРА СООБЩЕНИЙ) CALL-BACK WIN-PROC WIN-MSG WIN @ RECEPTING WIN-RET ; ( ОКОННАЯ Ф-ИЯ) Основные отличия от Вашей реализации (насколько понял): * использование дополнительного стека для регистров (чисто для наглядности), * сохранение туда же параметров оконной ф-ии (так удобнее в больших и сложных оконных ф-иях), * больше внимания уделено возможности рекурсивного вызова оконной ф-ии (и связи "вызывающих" и "вызываемых" FORTH-кусков), * вместо CASE win-сообщения разбираются конечным автоматом - RECEPTING, * в систему "сохранятелей" включен и цикл обработки сообщений. Думаю, Вам тоже проще было написать самому, чем разобраться в написанном мной. Поэтому приводить подобные "примеры" бесполезно. Проще указать на общую идею, чему, собственно, и была посвящена тема. Сравнению идей: что во что пихать и насколько глубоко.
[quote="Ethereal"]Так покажите как Вы написали сами. Хочу взглянуть...[/quote]Дык, оно уже пять лет лежит все там же: [url]http://www.gudleifr.h1.ru/g9/g2.txt[/url], как часть FOBOS ([url]http://www.gudleifr.h1.ru/cgi-bin/pilo.cgi?FL=../g9.txt&IS=\5.FOBOS[/url]). Там было так (ассемблер мой, он описан в начале упомянутого файла): [quote] ( ПРОСТОЕ СЛОВО ДЛЯ ВЫЗОВА ПРОЦЕДУРЫ - CALL . НЕ НАДО ЗАБЫВАТЬ, ЧТО: 1. ПОЧТИ ВСЕ ФУНКЦИИ WINDOWS СТРОЯТСЯ ПО ОБРАЗЦУ PASCAL - ПАРАМЕТРЫ ИЗ СТЕКА УДАЛЯЕТ САМА ФУНКЦИЯ; 2. СООТНЕСЕНИЕ ПЕРЕЧИСЛЕНИЯ ПАРАМЕТРОВ В СТРОКЕ C И ПОСЛЕДОВАТЕЛЬНОСТИ КОМАНД PUSH АССЕМБЛЕРА: СЛЕВА-НАПРАВО - СНИЗУ-ВВЕРХ. 3. ВЫЗОВ МНОГИХ Ф-ИЙ ПРИВОДИТ К ВЫЗОВУ ОКОННОЙ ПРОЦЕДУРЫ ) VARIABLE EDI-OLD ( ТЕКУЩАЯ ВЕРШИНА СЛОВАРЯ, КОТОРУЮ Ф-ИЯ МОЖЕТ ИЗМЕНИТЬ) VARIABLE EBP-OLD VARIABLE EBP-OLD2 ( ВЕРШИНА СТЕКА ВОЗВРАТОВ, КОТОРУЮ Ф-ИЯ ИЗМЕНИТЬ НЕ МОЖЕТ) CODE CALL ( ..., a -- w) /WO MOV, BP [DW] EBP-OLD , /WO MOV, DI [DW] EDI-OLD , CALLEW, B [RG] /DW MOV, B A [RG] /DW MOV, DI [DW] EDI-OLD , NEXT, END-CODE
...
\ БУФЕРА ДЛЯ ХРАНЕНИЯ MD-ЕРУНДЫ 64K ALLOCATE DROP CONSTANT WIN-STACK ( ДЛЯ ХРАНЕНИЯ КАДРОВ СТЕКА CALL-BACK-ОВ) VARIABLE WIN-SP WIN-STACK WIN-SP ! CREATE MSG 28 ALLOT
\ ОБРАМЛЕНИЕ ОКОННОЙ ПРОЦЕДУРЫ VARIABLE (GETMESSAGE) USER32 Z" GetMessageA" (FUNCTION) (GETMESSAGE) ! VARIABLE (TRANSLATEMESSAGE) USER32 Z" TranslateMessage" (FUNCTION) (TRANSLATEMESSAGE) ! VARIABLE (DISPATCHMESSAGE) USER32 Z" DispatchMessageA" (FUNCTION) (DISPATCHMESSAGE) ! ( САМОЕ ТОНКОЕ МЕСТО - СОХРАНЕНИЕ РЕГИСТРОВ и ВОССТАНОВЛЕНИЕ SI, DI, BP И BX, ИСПОЛЬЗУЕМЫХ MUST DIE ВНУТРИ СЕБЯ) CODE WIN-CYCLE ( -- w) ( БУДЕТ И ДРУГОЙ ВАРИАНТ - ДЛЯ ИЗВРАЩЕННЫХ ДИАЛОГОВ) /WO MOV, DI [DW] EDI-OLD , /WO MOV, BP [DW] EBP-OLD , 1 =H /DW XOR, A A [RG] A PUSHR, A PUSHR, A PUSHR, PUSHW, MSG , CALLEW, [DW] (GETMESSAGE) , /DW OR, A A [RG] ?ZR J, 2 =F PUSHW, MSG , CALLEW, [DW] (TRANSLATEMESSAGE) , PUSHW, MSG , CALLEW, [DW] (DISPATCHMESSAGE) , JMPSHORT, 1 =B 2 =H B PUSHR, /DW MOV, B [DW] MSG 8 + , /DW MOV, DI [DW] EDI-OLD , NEXT, END-CODE BEGIN-LOAD ASSEMBLER HEX : CALL-BACK CODE ( КОНЕЧНО НЕ ДЛЯ ВСЕХ CALL-BACK-ОВ, А ТОЛЬКО ДЛЯ ОКОННЫХ) /WO MOVA, WIN-SP , /WO MOV, DI A [8] 10 C, /WO MOV, SI A [8] 14 C, /WO MOV, B A [8] 18 C, /WO MOV, BP A [8] 1C C, C POPR, POPM, A [0] POPM, A [8] 4 C, POPM, A [8] 8 C, POPM, A [8] 0C C, C PUSHR, /SW ADDD, A [RG] 20 C, /DW MOVA, WIN-SP , /DW MOV, DI [DW] EDI-OLD , /DW MOV, BP [DW] EBP-OLD , SI MOVRDW, >MARK NEXT, >RESOLVE END-LOAD ] ; END-LOAD : WIN-H WIN-SP @ 32 - @ ; ( СООБЩЕНИЕ, СОХРАНЕННОЕ В КАДРЕ СТЕКА) : WIN-MSG WIN-SP @ 28 - @ ; : WIN-W WIN-SP @ 24 - @ ; : WIN-L WIN-SP @ 20 - @ ; CODE WIN-RET /WO MOV, BP [DW] EBP-OLD , A POPR, B PUSHR, ( ВОЗВРАТ ИЗ CALL-BACK) /WO MOV, DI [DW] EDI-OLD , /WO MOVA, WIN-SP , /SW SUBD, A [RG] 20 C, /DW MOV, DI A [8] 10 C, /DW MOV, SI A [8] 14 C, /DW MOV, B A [8] 18 C, /DW MOV, BP A [8] 1C C, /DW MOVA, WIN-SP , A POPR, RET, END-CODE
\ ОКОННАЯ ПРОЦЕДУРА USER32 WIN-FUNC" DEFWINDOWPROC DefWindowProcA" USER32 WIN-FUNC" POSTQUITMESSAGE PostQuitMessage" 2 CONSTANT WM_DESTROY : RECEPTOR ( <word> ... <;> w, wa, wa --) CREATE ROT , SWAP , , ] ; \ ПОЗДНЕЕ СВЯЗЫВАНИЕ РЕЦЕПТОРОВ : RECEPTOR+ ( брат, узел --) 4 + ! ; DOER !DESTROY : SUBRECEPTOR+ ( сын, узел --) 8 + ! ; ( ПОСЛЕДНИЕ В СПИСКЕ ПРОВЕРЯЕМЫХ СООБЩЕНИЙ - WIN-DESTROY И WIN-DEFAULT) 0 0 0 RECEPTOR WIN-DEFAULT WIN-L WIN-W WIN-MSG WIN-H DEFWINDOWPROC CALL ; WM_DESTROY WIN-DEFAULT 0 RECEPTOR WIN-DESTROY !DESTROY 0 POSTQUITMESSAGE CALL DROP 0 ; VARIABLE WIN ( ПЕРЕМЕННАЯ СОДЕРЖАЩАЯ АДРЕС КОРНЯ ДЕРЕВА РАЗБОРА СООБЩЕНИЙ) CALL-BACK WIN-PROC WIN-MSG WIN @ RECEPTING WIN-RET ; ( ОКОННАЯ Ф-ИЯ)[/quote] Основные отличия от Вашей реализации (насколько понял): * использование дополнительного стека для регистров (чисто для наглядности), * сохранение туда же параметров оконной ф-ии (так удобнее в больших и сложных оконных ф-иях), * больше внимания уделено возможности рекурсивного вызова оконной ф-ии (и связи "вызывающих" и "вызываемых" FORTH-кусков), * вместо CASE win-сообщения разбираются конечным автоматом - RECEPTING, * в систему "сохранятелей" включен и цикл обработки сообщений.
Думаю, Вам тоже проще было написать самому, чем разобраться в написанном мной. Поэтому приводить подобные "примеры" бесполезно. Проще указать на общую идею, чему, собственно, и была посвящена тема. Сравнению идей: что во что пихать и насколько глубоко.
|
|
|
|
Добавлено: Сб июн 06, 2015 10:57 |
|
|
|
|
|
Заголовок сообщения: |
Re: Forth на ... Это реально? - Попутное голосование |
|
|
gudleifr писал(а): Честно говоря, понять, что Вы сделали труднее, чем написать самому. Так покажите как Вы написали сами. Хочу взглянуть на реализацию, которую было написать проще, чем понять мою. Будет чему поучиться.
[quote="gudleifr"]Честно говоря, понять, что Вы сделали труднее, чем написать самому.[/quote]Так покажите как Вы написали сами. Хочу взглянуть на реализацию, которую было написать проще, чем понять мою. Будет чему поучиться.
|
|
|
|
Добавлено: Сб июн 06, 2015 06:54 |
|
|
|
|
|
Заголовок сообщения: |
Re: Forth на ... Это реально? - Попутное голосование |
|
|
gudleifr писал(а): Ethereal писал(а): ... Чтобы показать, что "сохранятели регистров" просты? Дело не в сохранятелях регистров как в таковых. Интересное в том, что переключение соглашений с Виндозных на Фортовские и обратно делается одним телодвижением. ОДНИМ действием (одним определяющим словом) вешается и переключение на входе и переключение на выходе.
[quote="gudleifr"][quote="Ethereal"]...[/quote]Чтобы показать, что "сохранятели регистров" просты?[/quote]Дело не в сохранятелях регистров как в таковых. Интересное в том, что переключение соглашений с Виндозных на Фортовские и обратно делается одним телодвижением. ОДНИМ действием (одним определяющим словом) вешается и переключение на входе и переключение на выходе.
|
|
|
|
Добавлено: Сб июн 06, 2015 06:52 |
|
|
|
|
|
Заголовок сообщения: |
Re: Forth на ... Это реально? - Попутное голосование |
|
|
gudleifr писал(а): Еще труднее понять, зачем Вы это сделали. Ну это очевидно-же. Чтобы писать графические приложения на той Форт-системе о которой ты знаешь все - это раз. Иногда такая нужна, если надо сделать нечто весьма нестандартное, поскольку свою систему легко доработать под это нестандартное. А вот чужую - нет. Чтобы увидеть минимальные для этого алгоритмы - это два. Прочувствовать проблематику этого дела - три. Чтобы пропереться, когда графическое приложение с оконной функцией на Форте (на твоем Форте !) заработает - четыре.
[quote="gudleifr"]Еще труднее понять, зачем Вы это сделали.[/quote]Ну это очевидно-же. Чтобы писать графические приложения на той Форт-системе о которой ты знаешь все - это раз. Иногда такая нужна, если надо сделать нечто весьма нестандартное, поскольку свою систему легко доработать под это нестандартное. А вот чужую - нет. Чтобы увидеть минимальные для этого алгоритмы - это два. Прочувствовать проблематику этого дела - три. Чтобы пропереться, когда графическое приложение с оконной функцией на Форте (на твоем Форте !) заработает - четыре.
|
|
|
|
Добавлено: Сб июн 06, 2015 06:45 |
|
|
|
|
|
Заголовок сообщения: |
Re: Forth на ... Это реально? - Попутное голосование |
|
|
Ethereal писал(а): ... Честно говоря, понять, что Вы сделали труднее, чем написать самому. Еще труднее понять, зачем Вы это сделали. Чтобы показать, что "сохранятели регистров" просты? А кто говорил, что они сложны?
[quote="Ethereal"]...[/quote]Честно говоря, понять, что Вы сделали труднее, чем написать самому. Еще труднее понять, зачем Вы это сделали. Чтобы показать, что "сохранятели регистров" просты? А кто говорил, что они сложны?
|
|
|
|
Добавлено: Пт июн 05, 2015 19:42 |
|
|
|
|
|
Заголовок сообщения: |
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.
В этом топике было сказано много слов. По моему лучше на практике попробовать есть ли какие проблемы, чем решать проблему еще не попробовав ее на вкус. Я попробовал тут к своему дурацкому Фиг-форту прикрутить оконные и диалоговые функции и очень изящно все получилось. Ввел определяющее слово CALL: для определения оконных функций так ( синтаксис FASM ) : [code] 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 [/code] После чего простейшая оконная функция оказалась такой : [code] CALL: WndProc ( lParam wParam Msg hWnd -- ... n ) OVER CASE WM_DESTROY OF 0 PostQuitMessage 0 ENDOF >R DefWindowProcA R> ENDCASE ; [/code] И это все.
Идея здесь такая. После определения 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 тут [code] MACRO NEXT$ { lodsd jmp dword [eax] } [/code] Когда шитокодное определение оконной функции завершается, управление улетает на DoWndProc_out. Этот код слово с вершины стека (я вершину стека в Фиг-форте храню в ebx) пихает в eax - это будет код возврата из оконной фунции. Далее из ebp восстанавливает esp и весь хлам со стека улетает. Далее восстанавливает со стека ebp edi esi ebx и завершает оконную функцию по ret 10h.
Все просто и не встретилось никаких проблем с чем-либо вообще.
P.S. Указатель стека данных в моем Фиг-форте - это esp. Указатель стека возвратов - ebp. Вершина стека данных в регистре ebx, остальное содержимое стека данных в аппаратном стеке esp.
|
|
|
|
Добавлено: Пт июн 05, 2015 19:22 |
|
|
|
|
|
Заголовок сообщения: |
Re: Forth на ... Это реально? - Попутное голосование |
|
|
Hishnik писал(а): Оно обоими способами и сращивается. Если большой системе нужна консоль/скриптовое управление, на ЯВУ пишется форт-машина и вставляется как статически скомпилированный модуль или dll, как удобнее. Если приложению, исходно написанному на Форте, требуется много стандартных функций, хорошо проработанных в других языках, оформляются фрагменты push-call-pop. Я выбрал 3 - по голосованию, или по Hishnik: на ЯВУ + inline ASM пишется форт-машина и вставляется как статически скомпилированный модуль. Думаю, что это компромисс между сложностью реализации самой форт системы и скоростью работы получившийся форт системы. Совершенно согласен с gudleifr, нужен отдельный стек возвратов для F, но я его пока не задействовал. Если я правильно понял, то в ядре SPF-Fork уже есть все механизмы для создания отдельного стека для F. Без него не реализовать рекурсию типа D --> F --> D --> F (и т.д.) А "сохранятели регистров" нужны в любом случае перехода D <--> F другое дело мы их писали явно или они уже встроены неявно, о чем и писал Ethereal.
[quote="Hishnik"]Оно обоими способами и сращивается. Если большой системе нужна консоль/скриптовое управление, на ЯВУ пишется форт-машина и вставляется как статически скомпилированный модуль или dll, как удобнее. Если приложению, исходно написанному на Форте, требуется много стандартных функций, хорошо проработанных в других языках, оформляются фрагменты push-call-pop.[/quote]
Я выбрал 3 - по голосованию, или по Hishnik: на ЯВУ + inline ASM пишется форт-машина и вставляется как статически скомпилированный модуль.
Думаю, что это компромисс между сложностью реализации самой форт системы и скоростью работы получившийся форт системы. Совершенно согласен с gudleifr, нужен отдельный стек возвратов для F, но я его пока не задействовал. Если я правильно понял, то в ядре SPF-Fork уже есть все механизмы для создания отдельного стека для F. Без него не реализовать рекурсию типа D --> F --> D --> F (и т.д.) А "сохранятели регистров" нужны в любом случае перехода D <--> F другое дело мы их писали явно или они уже встроены неявно, о чем и писал Ethereal.
|
|
|
|
Добавлено: Сб май 16, 2015 07:11 |
|
|
|
|
|
Заголовок сообщения: |
Re: Forth на ... Это реально? - Попутное голосование |
|
|
Ethereal писал(а): эти "сохранятели" толком и не требуются. Требуются, требуются... Назовем состояния регистров, соответственно для FORTH и Винды - F и W. Допустим, мы вызываем из FORTH ф-ию Win-API. И до и после запуска имеем F. Но нас это не устраивает по следующим причинам - ф-я Win-API может породить вызов оконной ф-ии, куда придет со значениями W. Надо откуда-то восстанавливать F. Более того, при возвращении оттуда возможно придется F модифицировать (например увеличить регистр HERE). Но, повторю, сложность/простота этого процесса к теме относится очень опосредованно.
[quote="Ethereal"]эти "сохранятели" толком и не требуются.[/quote]Требуются, требуются... Назовем состояния регистров, соответственно для FORTH и Винды - F и W. Допустим, мы вызываем из FORTH ф-ию Win-API. И до и после запуска имеем F. Но нас это не устраивает по следующим причинам - ф-я Win-API может породить вызов оконной ф-ии, куда придет со значениями W. Надо откуда-то восстанавливать F. Более того, при возвращении оттуда возможно придется F модифицировать (например увеличить регистр HERE). Но, повторю, сложность/простота этого процесса к теме относится очень опосредованно.
|
|
|
|
Добавлено: Сб май 16, 2015 01:58 |
|
|
|
|
|
Заголовок сообщения: |
Re: Forth на ... Это реально? - Попутное голосование |
|
|
gudleifr писал(а): Пардон, мне показалось, что у Вас просто приступ "блогородного негодования при виде столь поверхностного понимания". Нет. Просто Вы в фразе ""Пишем все на FORTH, а вызов ф-ий другой системы обвешиваем "сохранятелями регистров"" неудачно связали "сохранятели регистров" как-бы с вызовом функций Win-API из Форта, т.е. как раз с тем случаем когда эти "сохранятели" толком и не требуются.
[quote="gudleifr"]Пардон, мне показалось, что у Вас просто приступ "блогородного негодования при виде столь поверхностного понимания".[/quote]Нет. Просто Вы в фразе ""Пишем все на FORTH, а вызов ф-ий другой системы обвешиваем "сохранятелями регистров"" неудачно связали "сохранятели регистров" как-бы с вызовом функций Win-API из Форта, т.е. как раз с тем случаем когда эти "сохранятели" толком и не требуются.
|
|
|
|
Добавлено: Пт май 15, 2015 19:42 |
|
|
|
|
|
Заголовок сообщения: |
Re: Forth на ... Это реально? - Попутное голосование |
|
|
gudleifr писал(а): Ну, все-таки, и FORTH, и большинство систем, с которыми, мы его пытаемся обычно "срастить" - не совсем "черные ящики". Оно обоими способами и сращивается. Если большой системе нужна консоль/скриптовое управление, на ЯВУ пишется форт-машина и вставляется как статически скомпилированный модуль или dll, как удобнее. Если приложению, исходно написанному на Форте, требуется много стандартных функций, хорошо проработанных в других языках, оформляются фрагменты push-call-pop.
[quote="gudleifr"]Ну, все-таки, и FORTH, и большинство систем, с которыми, мы его пытаемся обычно "срастить" - не совсем "черные ящики".[/quote] Оно обоими способами и сращивается. Если большой системе нужна консоль/скриптовое управление, на ЯВУ пишется форт-машина и вставляется как статически скомпилированный модуль или dll, как удобнее. Если приложению, исходно написанному на Форте, требуется много стандартных функций, хорошо проработанных в других языках, оформляются фрагменты push-call-pop.
|
|
|
|
Добавлено: Пт май 15, 2015 19:24 |
|
|
|
|
|
Заголовок сообщения: |
Re: Forth на ... Это реально? - Попутное голосование |
|
|
Hishnik писал(а): Ответ - ту, которая меньше, в ту, которая больше. Ну, все-таки, и FORTH, и большинство систем, с которыми, мы его пытаемся обычно "срастить" - не совсем "черные ящики". Да и личные предпочтения на основе опыта должны были бы сформироваться.
[quote="Hishnik"]Ответ - ту, которая меньше, в ту, которая больше.[/quote]Ну, все-таки, и FORTH, и большинство систем, с которыми, мы его пытаемся обычно "срастить" - не совсем "черные ящики". Да и личные предпочтения на основе опыта должны были бы сформироваться.
|
|
|
|
Добавлено: Пт май 15, 2015 19:14 |
|
|
|
|
|
Заголовок сообщения: |
Re: Forth на ... Это реально? - Попутное голосование |
|
|
(4) - это ответ на вопрос: "у нас две коробки, зеленая и красная, какую в какую будем вставлять?". Ответ - ту, которая меньше, в ту, которая больше.
(4) - это ответ на вопрос: "у нас две коробки, зеленая и красная, какую в какую будем вставлять?". Ответ - ту, которая меньше, в ту, которая больше.
|
|
|
|
Добавлено: Пт май 15, 2015 19:07 |
|
|
|
|