Forth http://fforum.winglion.ru/ |
|
Поменять значения 2-х VALUE переменных http://fforum.winglion.ru/viewtopic.php?f=19&t=1202 |
Страница 5 из 5 |
Автор: | Forthware [ Ср мар 19, 2008 16:43 ] |
Заголовок сообщения: | |
chess писал(а): Привожу: Код: REQUIRE IDN ~chess\assm\sp-assm.f : VSWAP ' >BODY DUP ' >BODY DUP >CS C=@, SWAP >CS D=@, >CS @=D, >CS @=C, ; IMMEDIATE Вот так не работает: Код: V1 . V2 .
1 2 Ok VSWAP V1 V2 V1 . V2 . 1 2 Ok |
Автор: | chess [ Ср мар 19, 2008 19:04 ] |
Заголовок сообщения: | |
Forthware писал(а): Вот так не работает:
Пресловутая STATE-зависимость, ну вот так заработает: Код: REQUIRE IDN ~chess\assm\sp-assm.f
: VSWAP ' >BODY ' >BODY 2DUP STATE @ IF >CS C=@, >CS D=@, >CS @=D, >CS @=C, ELSE @ SWAP @ ROT ! SWAP ! THEN ; IMMEDIATE 1 VALUE V1 2 VALUE V2 V1 . V2 . VSWAP V1 V2 V1 . V2 . : TST VSWAP V1 V2 ; SEE TST TST V1 . V2 . Рантайм в интерактиве сам по себе малоинтересен - там быстродействие некритично, так как основное время сожрет поиск по словарю. А вот это по настоящему интересная задачка: сделать слово to не читающее из входного потока, под него сделать соответствующие value и vect. Основное требование - быстрый код реализации, Синтаксис использования - старый. Как вариант допускается использование таких to, value и vect только при компиляции. |
Автор: | Forthware [ Ср мар 19, 2008 20:41 ] |
Заголовок сообщения: | |
chess писал(а): Пресловутая STATE-зависимость, ну вот так заработает: Ага! chess писал(а): Рантайм в интерактиве сам по себе малоинтересен - там быстродействие некритично, так как основное время сожрет поиск по словарю. Так точно. chess писал(а): А вот это по настоящему интересная задачка: Ну так есть же вариант с флагом, который устанавливает ТО, а далше все решает сама переменная. Такое подойдет?
сделать слово to не читающее из входного потока, под него сделать соответствующие value и vect. Основное требование - быстрый код реализации, Синтаксис использования - старый. Как вариант допускается использование таких to, value и vect только при компиляции. Если такой вариант устраивает и дело только в скорости, то вот, пожалуй максимум что можно получить в рамкам ANSI и вообще переносимости: Код: CREATE $TO 0 , : $TO-VALUE ( A -- ) STATE @ IF POSTPONE LITERAL POSTPONE ! ELSE ! THEN 0 $TO ! ; : $DO-VALUE ( A -- ) STATE @ IF POSTPONE LITERAL POSTPONE @ ELSE @ THEN ; : $DO-VECT ( A -- ) STATE @ IF POSTPONE LITERAL POSTPONE @ POSTPONE EXECUTE ELSE @ EXECUTE THEN ; : TO TRUE $TO ! ; IMMEDIATE : IS POSTPONE TO ; IMMEDIATE : VALUE CREATE , IMMEDIATE DOES> $TO @ IF $TO-VALUE ELSE $DO-VALUE THEN ; : VECT CREATE ['] ABORT , IMMEDIATE DOES> $TO @ IF $TO-VALUE ELSE $DO-VECT THEN ; Смотрим в СПФ: Код: >1 VALUE V1 С использованием ассемблера, конечно можно быстрее (особенно VECT).
Ok >: @V1 V1 ; Ok >: !V1 TO V1 ; Ok >SEE @V1 587100 8945FC MOV FC [EBP] , EAX 587103 A1E0705800 MOV EAX , 5870E0 ( V1+5 ) 587108 8D6DFC LEA EBP , FC [EBP] 58710B C3 RET NEAR END-CODE Ok >SEE !V1 587120 8905E0705800 MOV 5870E0 ( V1+5 ) , EAX 587126 8B4500 MOV EAX , 0 [EBP] 587129 8D6D04 LEA EBP , 4 [EBP] 58712C C3 RET NEAR END-CODE Ok >VECT V2 Ok >' @V1 TO V2 Ok >: GOV2 V2 ; Ok >SEE GOV2 587170 8B0D50715800 MOV ECX , 587150 ( V2+5 ) 587176 8BD1 MOV EDX , ECX 587178 FFD2 CALL EDX 58717A C3 RET NEAR END-CODE Ok Однако уточните это ли вы имеете ввиду. |
Автор: | Forthware [ Ср мар 19, 2008 20:56 ] |
Заголовок сообщения: | |
А вот в VFX и VECT получился вполне ассемблерный: Код: 1 value v1 ok
vect v2 ok : v1. v1 . ; ok ' v1. to v2 ok : xx v2 ; ok see xx XX ( 004ABEE0 FF1590BE4A00 ) CALL [004ABE90] V2 ( 004ABEE6 C3 ) NEXT, ( 7 bytes, 2 instructions ) ok |
Автор: | chess [ Чт мар 20, 2008 15:11 ] |
Заголовок сообщения: | |
Forthware писал(а): Ну так есть же вариант с флагом, который устанавливает ТО, а далше все решает сама переменная. Такое подойдет?
Та же идея насчет переменной управляющей направлением передачи данных в адрес или из адреса реализованная не в рантайме, а во время компиляции. Конечно пойдет. Причем эта переменная "закрыта" от доступа даже лучше чем STATE(ну нет необходимости ее трогать программисту непосредственно). Что касается скорости кода - для VALUE по-моему предельно возможная(спасибо оптимизатору), а у вас что - другое мнение(?). Для вектора можно поддержать ассм-ом и будет тоже предельная. Совместимость с АНСИ, если вы не поняли, меня не интересует. Вообщем хорошее решение. Только $TO лучше определить через USER-CREATE (для многопоточности). |
Автор: | Forthware [ Чт мар 20, 2008 16:09 ] |
Заголовок сообщения: | |
chess писал(а): Та же идея насчет переменной управляющей направлением передачи данных в адрес или из адреса реализованная не в рантайме, а во время компиляции. Совершенно верно.chess писал(а): Что касается скорости кода - для VALUE по-моему предельно возможная(спасибо оптимизатору), а у вас что - другое мнение(?). Нет, я имел ввиду VECT. Неудачно выразился. chess писал(а): Совместимость с АНСИ, если вы не поняли, меня не интересует. Тем не менее, она достигнута. Пусть будет как бонус. chess писал(а): Только $TO лучше определить через USER-CREATE (для многопоточности). Да, наверно.
|
Автор: | Alexander [ Чт мар 27, 2008 15:25 ] |
Заголовок сообщения: | |
V1 V2 TO V1 TO V2 Вообще-то надо помнить о семантике слов и не забывать то, что данные лежат на вершине стека данных P.S. Чем проще решение, тем меньше кода. Ссмысла гонятся за скоростью на современных ПК и МК нет. |
Автор: | Forthware [ Чт мар 27, 2008 16:47 ] |
Заголовок сообщения: | |
To Alexander: http://fforum.winglion.ru/viewtopic.php?p=13396#13396 Однако не понятно к чему ваш ответ? Условиям оригинальной задачи chess решение "V1 V2 TO V1 TO V2" не соответствует, ибо сказано: "На стеке параметров перед присвоением должен лежать только один параметр.", а к задаче Garbler не имеет ввобще никакого отношения. К чему все это? |
Автор: | Alexander [ Пт мар 28, 2008 08:37 ] |
Заголовок сообщения: | |
Итак у меня возникли вопросы: 1) зачем экономить память стека данных, если даже для любой арифметической операции нужно две ячейки; 2) применение слова VALUE оправдано лишь в случае редкого изменения хранимого значения и частого его получения, например, для хранения идентификаторов (дескрипторов); 3) Возможно, что применение слова VARIABLE улучшило бы читаемость алгоритма и переписывание его на ассемблер с применением инструкции XCHG. Тогда у вас будет задействована только вершина стека (в большинстве случаев это регистр процессора), но только в том случае если адреса переменных известны заранее и вы не собираетесь их передавать в качестве параметров для выполнения вновь созданного слова. |
Автор: | Forthware [ Пт мар 28, 2008 13:14 ] |
Заголовок сообщения: | |
Alexander писал(а): 1) зачем экономить память стека данных, если даже для любой арифметической операции нужно две ячейки; Потому что такие условия задачи. Очевидно, что они совершенно виртуальны и никакого отношения к реальности не имеют. На то она и задача. Alexander писал(а): 2) применение слова VALUE оправдано лишь в случае редкого изменения хранимого значения и частого его получения, например, для хранения идентификаторов (дескрипторов); А это уже кому как. Конечно, доступ к изменению VALUE куда как хуже чем VARIABLE, однако он есть, и не факт что полученный код будет медленнее (смотри примеры выше). Так что вполне возможно что кому то удобнее работать с VALUE всегда. К тому же, обычная (ANSI) реализация локальных переменных использует тот же принцип доступа что и VALUE, при этом вы ведь не скажете что локальные переменные оправдано использовать лишь в случае редкого изменения хранимого значения? Верно? Alexander писал(а): 3) Возможно, что применение слова VARIABLE улучшило бы читаемость алгоритма и переписывание его на ассемблер с применением инструкции XCHG. Улучшило бы, конечно! Но не соответствует условиям задачи. А насчет XCHG, почитайте больше про эту комманду в доках от изготовителей процессоров. Если мне память не изменяет, она не просто медленнее (особенно с памятью), но там еще есть риск зависания конвейера, к тому же использует медленный декодер...
|
Автор: | Alexander [ Пт мар 28, 2008 14:27 ] |
Заголовок сообщения: | |
Forthware писал(а): А насчет XCHG, почитайте больше про эту комманду в доках от изготовителей процессоров. Если мне память не изменяет, она не просто медленнее (особенно с памятью), но там еще есть риск зависания конвейера, к тому же использует медленный декодер...
Ага, если внимательно прочитать про 5 исполнительных устройств Пентиума, то там только одно которе умеет работать с памятью. Вот реализация под SwiftForth Код: 1 value v1 2 value v2
code test ' v1 >body eax addr ' v2 >body ecx addr ebx 0 [eax] xchg ebx 0 [ecx] xchg ebx 0 [eax] xchg ret end-code |
Автор: | Forthware [ Пт мар 28, 2008 18:01 ] |
Заголовок сообщения: | |
Не знаю как у кого, но у меня ваш вариант получился приблизительно в 100 раз медленнее за V1 V2 TO V1 TO V1. Берем SwiftForth, делаем: Код: 1 value v1 2 value v2
code t1 ' v1 >body eax addr ' v2 >body ecx addr ebx 0 [eax] xchg ebx 0 [ecx] xchg ebx 0 [eax] xchg ret end-code : t2 v1 v2 to v1 to v2 ; : tt1 counter 100000000 0 do t1 loop counter swap - . ; : tt2 counter 100000000 0 do t2 loop counter swap - . ; Запускаем tt1 и tt2 и смотрим на циферки. |
Автор: | Alexander [ Пн мар 31, 2008 09:14 ] |
Заголовок сообщения: | |
Forthware писал(а): Запускаем tt1 и tt2 и смотрим на циферки Ответ очень прост, если взглянуть на документацию к инструкциям. XCHG хотите вы этого или нет всегда генерирует префикс LOCK. Цитата: See “Effects of a Locked Operation on Internal Processor Caches” in Chapter 7 of Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A, the for more information on locking of caches.
Также надо не забывать про параллельность выполнения. |
Автор: | Forthware [ Пн мар 31, 2008 11:57 ] |
Заголовок сообщения: | |
Alexander писал(а): Ответ очень прост Ага - не надо использовать XCHG, о чем я и предупреждал. Alexander писал(а): если взглянуть на документацию к инструкциям. Таки последовали моему совету? Хорошо! Плохо только что уже после того как предложили заведомо провальный вариант. Цитата: XCHG хотите вы этого или нет всегда генерирует префикс LOCK. Что-ж, хрен редьки не слаще. Надеюсь теперь вы согласны что не стоит использовать XCHG reg, mem ?
Кстати, насчет XCHG reg, reg похоже не все так плохо, только сложный декодер используется и вроде все. Но в нашем случае нет пользы от использования данной комманды. |
Страница 5 из 5 | Часовой пояс: UTC + 3 часа [ Летнее время ] |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |