Поменять значения 2-х VALUE переменных

chess

Forthware писал(а):

Безусловно, с переносом именно эта задача решается проще. Однако учтите, что реализация переноса предложенным вами способом (LSHIFTC и RSHIFTC ваш пример реализации), требует чтобы либо все остальные слова Форта гарантированно не влияли на флаг переноса, что неоправданно сложно реализовать, либо придется составить список слов которые влияют на этот флаг, что усложнит язык и его спользование, увеличит риск возникновения ошибок.

Неубедительно это все. Во-первых никто не запрещает флаг переноса сохранять когда это нужно и где это
удобно. Во-вторых слова D2* D2/ также перенос используют как и LSHIFTC и RSHIFTC.

Forthware писал(а):

Нет, именно тип. Например, можно создать:
DVALUE , SVALUE , FVALUE. Первое будет хранить двойное число, второе - строку, третье число с плавающей точкой. При этом, предполагается что TO будет работать со всеми одинаково.

Мое мнение - еще одно плохое решение в стандарте - одно слово должно быть корректным по отношению ко многим другим да еще и с неизвестными заранее форматами.
Есть глобальная переменная STATE - ее программист менять может, а тут глобальная переменная, которую программист менять не может с абсолютно однозначной функцией - и это плохо.

Forthware

chess писал(а):

Неубедительно это все.

Хорошо, попробуем по другому.

В виртуальной Форт машине нет регистра хранящего флаг переноса. Поэтому есть два варианта передачи его от одной комманды к другой. Или мы сохраняем его на стеке данных, тогда LSHIFTC будет иметь нотацию ( u f -- u f ), или добавляем в машину этот регистр, предположительно в виде глобальной переменной, или же скрытый от программиста. Первый вариант по эффективности будет не многим лучше работы с числами двойной длины, второй лучше, но все-равно менее эффективен чем использование флага переноса реального процессора, поскольку требует записи и чтения. А флаг процессора использовать нельзя поскольку другие комманды делают с ним что хотят.

chess писал(а):

Во-вторых слова D2* D2/ также перенос используют как и LSHIFTC и RSHIFTC.

Нет, в D2* флаг используется внутри кода комманды, в то время как в последовательности: LSHIFTC SWAP 1 RSHIFTC , флаг должен остаться неизмененным при выполнении комманды SWAP и литерала 1 поскольку он будет использован как аргумент RSHIFTC.

chess писал(а):

Мое мнение - еще одно плохое решение в стандарте - одно слово должно быть корректным по отношению ко многим другим да еще и с неизвестными заранее форматами.

Никто не заставляет им пользоваться, как я уже говорил. Оно не добавляет новой функциональности, поскольку все что делает VALUE можно сделать с помощью VARIABLE. Другое дело локальные переменные, но это другой вопрос.
Насчет неизвестных форматов и т. д. Вот пример реализации всех перечисленных мною вариантов VALUE на ANSI:

Код:

: TO ' >BODY DUP @ STATE @ IF SWAP POSTPONE LITERAL POSTPONE COMPILE, ELSE EXECUTE THEN ; IMMEDIATE 
:NONAME CELL+ ! ;
: VALUE CREATE LITERAL , , DOES> CELL+ @ ;
:NONAME CELL+ 2! ;
: DVALUE CREATE LITERAL , , , DOES> CELL+ 2@ ;
:NONAME SWAP 256 MIN SWAP CELL+ 2DUP ! CELL+ SWAP CMOVE ;
: SVALUE CREATE LITERAL , DUP , HERE 256 CHARS ALLOT SWAP CMOVE DOES> CELL+ DUP CELL+ SWAP @ ;
:NONAME CELL+ F! ;
: FVALUE CREATE LITERAL , HERE F! 1 FCELLS ALLOT DOES> CELL+ F@ ;

Любой неизвестный формат добавляется двумя строчками, как видите.

chess писал(а):

Есть глобальная переменная STATE - ее программист менять может,

Нет, не может. Вернее, в соответствии с ANSI, ее можно читать, но непостредственно писать в STATE запрещено (коммитет не ручается за последствия

).

chess писал(а):

а тут глобальная переменная, которую программист менять не может с абсолютно однозначной функцией - и это плохо.

Как не может? Для этого есть TO. Или я вас не понял?
Все это для того и делалось чтобы избавиться от непосредственных указателей. Зачем? Во первых, реализации хранения данных могут быть разными вплоть до хранения в регистрах процессора. Не всегда возможно использовать указатель, не всегда он постоянен, и т.д. Теоретически, VALUE вообще может хранить информацию в файле или вообще в онлайне и совершать запись и чтение через FTP. Такой механизм позволяет скрыть реализацию от программиста, что дает возможность писать более переносимые программы. Если при этом вы дадите возможность получения указателя на данные хранящиеся в VALUE, то все это станет невозможным и сам смысл существования VALUE TO будет под вопросом. Понимаете?

chess

Forthware писал(а):

Нет, не может. Вернее, в соответствии с ANSI, ее можно читать, но непостредственно писать в STATE запрещено (коммитет не ручается за последствия ).

Для этого есть два слова: [ и ].

А с флагами реализация куда проще и быстрее.

Код:

USER st-val  st-val 0!

: to  1 st-val ! ;
: value   CREATE ,    DOES> st-val @ IF  ! st-val 0! ELSE  @ THEN ;
: dvalue  CREATE , ,  DOES> st-val @ IF 2! st-val 0! ELSE 2@ THEN ;
..... и т.д.

true-grue

Forthware писал(а):

Вот пример реализации всех перечисленных мною вариантов VALUE на ANSI:

Код:

: TO ' >BODY DUP @ STATE @ IF SWAP POSTPONE LITERAL POSTPONE COMPILE, ELSE EXECUTE THEN ; IMMEDIATE 
:NONAME CELL+ ! ;
: VALUE CREATE LITERAL , , DOES> CELL+ @ ;
и т.д.

Этот и большая часть прочего форумного кода от г-на Forthware грубо не соответствуют ANS в одном тонком, но важном моменте. Кто-нибудь догадается, в чем тут дело?

Forthware

chess писал(а):

Для этого есть два слова: [ и ].

А дла VALUE есть TO.

chess писал(а):

с флагами реализация куда проще и быстрее.

Быстрее? Это если при каждом обращении к переменной сначало идет чтение USER переменной, потом условное ветвление, только после этого нужный нам код и опять запись литерала в переменную? И все в рантайме? По моему вы заблуждаетесь.

true-grue писал(а):

Этот и большая часть прочего форумного кода от г-на Forthware грубо не соответствуют ANS в одном тонком, но важном моменте. Кто-нибудь догадается, в чем тут дело?

Я знаю!

В данном фрагменте есть системная зависимость, поскольку предполагается реализация отдельного CS. Если же CS использует DS, то XT от :NONAME нельзя передавать таким образом как аргумент для LITERAL в следующем определении.

in4

forther писал(а):

in4 писал(а):

Нет заморочек с предыдущим левым переносом

Нет никакого левого переноса.

В системе команд 8-битового PIC16F877- микроконтроллера нет команды "сложить/вычесть с переносом". Для сложения и вычитания 16-битных чисел приходится применять дополнительные команды, корректирующие перенос. В случае с XOR такой необходимости нет! А как раз для таких контроллеров с памятью ~128..256..384 байтов на всё - предложенная задача особенно актуальна.

garbler

chess писал(а):

анси-несовместимое решение для задачки garblera

Код:

1 VALUE V1
2 VALUE V2

: VSWAP1  2DUP 5 + @ SWAP 5 + @ ROT 5 + ! SWAP 5 + ! ;

' V1 ' V2 VSWAP1  

: VSWAP2 ' ' VSWAP1 ;

VSWAP2 V1 V2  

это не будет работать для режима компиляции, наверное, мне следовало
оговорить это в условии..... что я просто подразумевал

Forthware

in4 писал(а):

А как раз для таких контроллеров с памятью ~128..256..384 байтов на всё - предложенная задача особенно актуальна.

Ну, если подумать, то для форта она не актуальна вообще. Почему? Для работы самого простого решения (через XOR, как предложил WingLion) необходимо 2 свободных ячейки на стеке данных, потому что комманда XOR берет 2 аргумента. Однако, для реализации обмена таким образом: V1 V2 TO V1 TO V2 надо ровно столько же - 2 ячейки на стеке. К тому же, последнее заметно быстрее, поскольку не выполняет трех XOR-ов и имеет 2 чтения и 2 записи в память, в то время как арифметический вариант - 6 чтений и 3 записи. Ну и в заключение, что тоже важно для малых систем, размер полученного кода опять же меньше, если мы не используем арифметики/логики. Поэтому я не вижу как эта задача вообще может быть актуальной для Форта? В чем преимущество?

in4

Forthware писал(а):

В чем преимущество?

Преимущество проявится при оптимизации в нативном коде на указанных системах. Либо при реализации ФВМ. SWAP 2х 8-битовых переменных займет 3 команды, что лучше, чем с использованием промежуточной переменной.

Forthware

in4 писал(а):

Преимущество проявится при оптимизации в нативном коде на указанных системах. Либо при реализации ФВМ. SWAP 2х 8-битовых переменных займет 3 команды, что лучше, чем с использованием промежуточной переменной.

То есть, в ассемблере. Верно? А мы говорим о Форте. :shuffle;

Насчет ассемблера, совершенно согласен. Если мне память не изменяет, то я это реально использовал на к580 в старые добрые времена - регистров нехватало всегда, а push/pop медленный...

Так что для ассемблеров некоторых процессоров это действительно актуальная проблема. Но не для Форта.

chess

garbler писал(а):

это не будет работать для режима компиляции, наверное, мне следовало
оговорить это в условии..... что я просто подразумевал

Код:

: VSWAP1 ( xt1 xt2 -- ) >BODY SWAP >BODY 2DUP @ SWAP @ ROT ! SWAP ! ;
: VSWAP2 ' ' STATE @ IF  POSTPONE 2LITERAL  POSTPONE VSWAP1 ELSE  VSWAP1 THEN ; IMMEDIATE 

chess

Для ускорения исполнения в рантайме можно написать VSWAP1 в маш. командах:

Код:

REQUIRE IDN ~chess\assm\sp-assm.f

: VSWAPc \ xt1 xt2 --
  B=@P $ 5 C=@B $ 5 D=@A $ 5 @B=D $ 5 @A=C 2DROP ;

: VSWAP1 \ xt1 xt2 --
  >BODY SWAP >BODY 2DUP @ SWAP @ ROT ! SWAP ! ;

STARTLOG
SEE VSWAPc
SEE VSWAP1

лог
CODE VSWAPc
5A5B10 8B5D00           MOV     EBX , 0 [EBP]
5A5B13 8B4B05           MOV     ECX , 5 [EBX]
5A5B16 8B5005           MOV     EDX , 5 [EAX]
5A5B19 895305           MOV     5 [EBX] , EDX
5A5B1C 894805           MOV     5 [EAX] , ECX
5A5B1F 8B4504           MOV     EAX , 4 [EBP]
5A5B22 8D6D08           LEA     EBP , 8 [EBP]
5A5B25 C3               RET     NEAR
END-CODE

CODE VSWAP1
5A5B40 8D4005           LEA     EAX , 5 [EAX]
5A5B43 8B5500           MOV     EDX , 0 [EBP]
5A5B46 894500           MOV     0 [EBP] , EAX
5A5B49 8D4205           LEA     EAX , 5 [EDX]
5A5B4C 8B5500           MOV     EDX , 0 [EBP]
5A5B4F 8B08             MOV     ECX , [EAX]
5A5B51 894DF8           MOV     F8 [EBP] , ECX
5A5B54 8B0A             MOV     ECX , [EDX]
5A5B56 8B55F8           MOV     EDX , F8 [EBP]
5A5B59 8908             MOV     [EAX] , ECX
5A5B5B 8B4500           MOV     EAX , 0 [EBP]
5A5B5E 8910             MOV     [EAX] , EDX
5A5B60 8B4504           MOV     EAX , 4 [EBP]
5A5B63 8D6D08           LEA     EBP , 8 [EBP]
5A5B66 C3               RET     NEAR
( в 2 раза быстрее )

PS. Так как размер и смещение относительно XT у поля BODY одинаковы для VALUE, VARIABLE и VECT, то
VSWAP2 будет работать корректно для любой комбинации этих переменных.

VSWAP VAL1 VAR1
VSWAP VAR2 VECT1

Forthware

Однако есть вариант который совершенно системно независим, и к тому же быстрее!

Вот он:

Код:

: VSWAP ( "v1 v2" -- )
>IN @ PAD 2 0 DO BL WORD COUNT CHARS TUCK 3 PICK SWAP MOVE + BL OVER C! CHAR+ LOOP SWAP >IN !
2 0 DO S"  TO " CHARS TUCK 3 PICK SWAP MOVE + BL WORD COUNT CHARS TUCK 3 PICK SWAP MOVE + LOOP
PAD SWAP OVER - EVALUATE ; IMMEDIATE

Чтобы убедиться какой код получается в результате его использования под SPF делаем:

Код:

1 VALUE V1 2 VALUE V2
 Ok
: TEST VSWAP V1 V2 ;
 Ok
SEE TEST

587060 8945FC           MOV  FC [EBP] , EAX 
587063 A125705800       MOV  EAX , 587025  ( V1+5  ) 
587068 8B0D45705800     MOV  ECX , 587045  ( V2+5  ) 
58706E 890D25705800     MOV  587025  ( V1+5  ) , ECX 
587074 A345705800       MOV  587045  ( V2+5  ) ,  EAX
587079 8B45FC           MOV  EAX , FC [EBP] 
58707C C3               RET  NEAR 
END-CODE   Ok

chess

Forthware писал(а):

Однако есть вариант который совершенно системно независим, и к тому же быстрее!

Точнее - соответствует АНСИ.

А насчет скорости - тот же код, что и в варианте

Код:

: TST V1 V2 TO V1 TO V2 ;

(То есть из записи VSWAP V1 V2 делаем запись V1 V2 TO V1 TO V2 ),
а код такой потому, что оптимизатор поработал.

Оптимальнее только такой код мог быть(если не трогать стек-а это и не надо).

Код:

MOV  EBX , 587025  ( V1+5  ) 
MOV  ECX , 587045  ( V2+5  ) 
MOV  587025  ( V1+5  ) , ECX 
MOV  587045  ( V2+5  ) , EBX 
RET  NEAR 

Forthware

chess писал(а):

Точнее - соответствует АНСИ.

Да нет, этот вариант можно использовать на совершенно любом форте имеющем VALUE и EVALUATE, а это практически все нормальные реализации. При этом мы никак не полагаемся на реализацию VALUE - она может быть совершенно произвольной.

chess писал(а):

(То есть из записи VSWAP V1 V2 делаем запись V1 V2 TO V1 TO V2 ),

Ну я ведь привел исходник. В нем так и написано.

И это есть самый оптимальный вариант из возможных независимых от реализации. К тому же, скорее всего, он компилируется любым Фортом в более эффективный код, чем попытки менять значения в телах переменных с помощью @ и ! . Только с помощью ассемблера можно получить что-то лучше, но ассемблер не есть форт, в нем всегда все лучше, только сложнее и не переносимо. :roll:

chess писал(а):

а код такой потому, что оптимизатор поработал.

Да, конечно, но результат для SPF получисля более эффективным чем ваш код на ассме. А на других Фортах ваш код вообще не работает в отличии от этого.

chess писал(а):

Оптимальнее только такой код мог быть(если не трогать стек-а это и не надо).

Да, быстрее пожалуй не сделать. Тем не менее, приведенный вами ранее результат далек от этого, особенно если посмотреть как он компилируется:

Код:

: TEST VSWAP2 V1 V2 ; 
SEE TEST

Поменять значения 2-х VALUE переменных

Кто сейчас на конференции