RFS, замечания от Ethereal

Hishnik

chess писал(а):

Это наверное в кварке так.

Такое разъяснение было, кажется, у Баранова. Насчет Броуди не помню, но возможно. В любом случае, где-то есть упоминание о том, что команды вида 1+ 2* и прочие могут иметь целью не только более компактную запись, но и более быструю и компактную машинную реализацию.

Alexander

Раздули из мухи слона
Кто не в курсе про арифметические и логические сдвиги влево что это одна и та же команда?(команды умножения на степень числа 2). деление на степень числа 2,то команды разные - одна для знаковых дргуая для безнаковых. А потом все зависит от операционного устройства что же лучше команда сложения или сдвига . Может делить проще путем вычитания???
из мануала по инструкциям процесора

Цитата:

Using the SAR instruction to perform a division operation does not produce the same result as
the IDIV instruction. The quotient from the IDIV instruction is rounded toward zero, whereas
the “quotient” of the SAR instruction is rounded toward negative infinity. This difference is
apparent only for negative numbers. For example, when the IDIV instruction is used to divide
-9 by 4, the result is -2 with a remainder of -1. If the SAR instruction is used to shift -9 right by
two bits, the result is -3 and the “remainder” is +3; however, the SAR instruction stores only the
most significant bit of the remainder (in the CF flag).

Так что ничего сложного.

Alexander

Wlad писал(а):

Возмём любой язык с инфиксной записью операций.

int i,j;
double d;

j = 4;
i = j / 2;
d = j / 2;

Наверняка значение d, приведённое к int окажется не 2.

после исполнения деления D окажется равным НУЛЮ!!! Потому как этому С надо явное приведение типов между int и double . Может современные компиляторы не страдают этим, но я один раз такую граблю ловил. Долго думал где проблема ... А то что имелось в виду что не совсем 2 так это проблема округления в сопроцессоре . по умолчанию до ближайшего, а зачастую в счете применятся операция отбрасывания лишних бит (отсечения)

Wlad

Alexander писал(а):

после исполнения деления D окажется равным НУЛЮ!!!

Ну, - конечно! Щаз.
И сдвиг у нас - деление.
И inc - это add ,1...

Скорблю.

Alexander

Wlad
Не надо переживать так сильно.
Вообще современные процесоры Pentium умеют переупорядовачивать инструкции, а также раскидывать их на паралленые вычислители. Так вот согласно документации на эти процессоры, я в свое время не поленился и почитал внимательно 600 страниц, команда inc может приостановить такое счастье и ввести процессор в ожидание установки флага переноса.
Команда inc полезна для процессоров производных от pentium pro, а это процессоры для ноутбуков. - в остальных же случаях лучше add. Проверено, особеено если вы делаете это в цикле. вообще правила ускорения выполнения операций о котрых знает сам производитель публикуются. в общем тут уже не отнсится к теме 2 / и 2/. Обяснение выше.

вопрос

Когда-то давно читал совет не помещать единицу в регистр непосредственно
mov EAX, 01h
а обнулять регистр и увеличивать на 1 инкрементом
xor EAX,EAX
inc EAX

Wlad

Alexander писал(а):

Wlad
Не надо переживать так сильно.
Вообще современные процесоры Pentium умеют переупорядовачивать инструкции, а также раскидывать их на паралленые вычислители. Так вот согласно документации на эти процессоры, я в свое время не поленился и почитал внимательно 600 страниц, команда inc может приостановить такое счастье и ввести процессор в ожидание установки флага переноса.
Команда inc полезна для процессоров производных от pentium pro, а это процессоры для ноутбуков. - в остальных же случаях лучше add. Проверено, особеено если вы делаете это в цикле. вообще правила ускорения выполнения операций о котрых знает сам производитель публикуются. в общем тут уже не отнсится к теме 2 / и 2/. Обяснение выше.

Куда вас всех несёт?...

Я всё думаю, кто же первый задасться вопросом, почему же для РАЗНЫХ, ПО СЕМАНТИКЕ, КОМАНД выбрали "типа одинаковую" последовательность символов?

mOleg

Wlad писал(а):

Я всё думаю, кто же первый задасться вопросом, почему же для РАЗНЫХ, ПО СЕМАНТИКЕ, КОМАНД выбрали "типа одинаковую" последовательность символов?

а я уже возмутился по этому поводу между прочим.
причем, не "типа одинаковую" а визуально одинаковую - сознание такая вредная штука - пробел может и не замечать, что называется в упор. В форке я убрал напрочь 1+ 2+ 4+ CELL+ 2/ 4/ и прочая, оставил только CELLS, и считаю это правильным!

chess

Wlad писал(а):

Я всё думаю, кто же первый задасться вопросом, почему же для РАЗНЫХ, ПО СЕМАНТИКЕ, КОМАНД выбрали "типа одинаковую" последовательность символов?

Вопрос тут немного сложнее. Где гарантия, что ОДИНАКОВАЯ СЕМАНТИКА для команд из одинаковой последовательности символов для исходного состояния форта не станет разной при расширении форта(например при введении в словарь FORTH встроенного ассемблера). К 2/ и 2 / это не относится, так как для исходного форта(я здесь под исходным фортом подразумеваю только spf4.exe) 2/ и 2 / имеют разную семантику, что, кстати, тоже смотрится ненормально, но это еще можно стерпеть без особого напряжения(хотя все-же лучше заменить 2/, например, на 1SAR)?
Запрет такого рода расширений считаю ненормальным для форта. Поэтому считаю, что Wlad прав - за основу все-таки надо брать
не относительную семантику, а базовую - семантику команд целевой платформы. В этом случае исключается
искажение семантики при любых расширениях форта. Побочное следствие - более однозначный процесс совмещения ПО, выполненного с использованием разных Форт-систем.
А так, при введении встроенного ассемблера пришлось 'присмотреться' к словам типа 1+, 2+, 1-, 2- и использовать их только когда можно. Это небольшой труд, но все-же..

Alexander

итак, смысл слов 2/ и 4/ и CELLS/ .
их надо применять к тем данным что вы считаете безнаковыми и тогда все будет хорошо -семантика совпадет.
отказ от +CELL И -CELL могут сделать код неудобоваримым.
1+ и 1 + одинаково тракутются.
2 / и 2/ одинаково для беззнаковых чисел. для знаковых выход очевиден путем патча:

Код:

: 2/ NEGATE 2/ NEGATE ;

Итак эффективность реализации в машинных кодах можно отдельно пообсуждать.

dynamic-wind

вопрос писал(а):

Когда-то давно читал совет не помещать единицу в регистр непосредственно
mov EAX, 01h
а обнулять регистр и увеличивать на 1 инкрементом
xor EAX,EAX
inc EAX

Код:

   0:   b8 01 00 00 00          mov    $0x1,%eax
   5:   31 c0                   xor    %eax,%eax
   7:   ff c0                   inc    %eax

Экономия аж байт.

chess

Alexander писал(а):

1+ и 1 + одинаково тракутются.

Вы меня не поняли. Тогда объясню на примере:

Код:

DIS-OPT
STARTLOG

: s1 -1 1+   L1 JC  1 .  L1: 2 . CR ; SEE s1
: s2 -1 1 +  L1 JC  1 .  L1: 2 . CR ; SEE s2

s1 s2

лог

Код:

CODE s1
5D181B 8945FC           MOV     FC [EBP] , EAX
5D181E B8FFFFFFFF       MOV     EAX , # FFFFFFFF
5D1823 8D4001           LEA     EAX , 1 [EAX]                   \ это 1+
5D1826 8D6DFC           LEA     EBP , FC [EBP]
5D1829 7210             JB      5D183B
5D182B 8945FC           MOV     FC [EBP] , EAX
5D182E B801000000       MOV     EAX , # 1
5D1833 8D6DFC           LEA     EBP , FC [EBP]
5D1836 E8F54BF8FF       CALL    556430  ( . )
5D183B 8945FC           MOV     FC [EBP] , EAX
5D183E B802000000       MOV     EAX , # 2
5D1843 8D6DFC           LEA     EBP , FC [EBP]
5D1846 E8E54BF8FF       CALL    556430  ( . )
5D184B E84448F8FF       CALL    556094  ( CR )
5D1850 C3               RET     NEAR
END-CODE
( 54 bytes, 15 instructions )


CODE s2
5D1863 8945FC           MOV     FC [EBP] , EAX
5D1866 B8FFFFFFFF       MOV     EAX , # FFFFFFFF
5D186B 8D6DFC           LEA     EBP , FC [EBP]
5D186E 8945FC           MOV     FC [EBP] , EAX
5D1871 B801000000       MOV     EAX , # 1                        \  это 
5D1876 0345FC           ADD     EAX , FC [EBP]                  \  1 +
5D1879 7210             JB      5D188B
5D187B 8945FC           MOV     FC [EBP] , EAX
5D187E B801000000       MOV     EAX , # 1
5D1883 8D6DFC           LEA     EBP , FC [EBP]
5D1886 E8A54BF8FF       CALL    556430  ( . )
5D188B 8945FC           MOV     FC [EBP] , EAX
5D188E B802000000       MOV     EAX , # 2
5D1893 8D6DFC           LEA     EBP , FC [EBP]
5D1896 E8954BF8FF       CALL    556430  ( . )
5D189B E8F447F8FF       CALL    556094  ( CR )
5D18A0 C3               RET     NEAR
END-CODE
( 62 bytes, 17 instructions )
1 2
2

Как видите результаты работы 1+ и 1 + становятся разными при введении встроенного ассемблера.
Дело в том, что LEA не меняет флаг переноса, а ADD - меняет.
Переносы в исходном форте - понятие отсутствующее, а в расширенном( со встроенным ассемблером ) - присутствующее.
PS. Предварительное отключение оптимизатора необходимо потому, что оптимизатор подменяет код 1 + на код 1+.

Hishnik

chess писал(а):

Как видите результаты работы 1+ и 1 + становятся разными при введении встроенного ассемблера.
Дело в том, что LEA не меняет флаг переноса, а ADD - меняет.

А на что это на практике влияет, если флаг переноса в явном виде словами Форта не используется?

chess

Хищник писал(а):

А на что это на практике влияет, если флаг переноса в явном виде словами Форта не используется?

Ну да. В форте исходном флаг переноса как понятие не существует и поэтому ни на что не влияет. Тут речь пошла о расширении форта( конкретно это введение встроенного ассемблера). При этом понятие слова расширилось. Под словом теперь понимается не только слово форта в привычном понимании, но и лексемы, которые формируют код, но не имеют при этом словарных статей. Кроме того часть таких лексем это лексемы инструкций процессора. При этом совместное использование слов форта и лексем инструкций процессора выводит из небытия и понятие переноса и некоторые другие понятия(на самом деле их немного), относящиеся к харду. Совместное использование слов форта и лексем инструкций позволяет более гибко формировать код программ повышая производительность труда программиста и с другой стороны позволяет в критических местах ускорять код. Обобщая изложенное выше можно сказать, что форт расширен в части введения в него возможностей синтаксического разбора лексем и последующим формированием по результатам такого разбора соответствующего им кода. Нужно сказать, что зачатки это в форте уже были. Примером этому служит разбор и формирование кода для лексем чисел.

white_TigR

chess писал(а):

Как видите результаты работы 1+ и 1 + становятся разными при введении встроенного ассемблера.
Дело в том, что LEA не меняет флаг переноса, а ADD - меняет.
Переносы в исходном форте - понятие отсутствующее, а в расширенном( со встроенным ассемблером ) - присутствующее.
PS. Предварительное отключение оптимизатора необходимо потому, что оптимизатор подменяет код 1 + на код 1+.

А не правильнее ли будет, в таком случае, на этом же встроеном ассемблере и писать весь кусок кода, вместо мешанины форта и асма?
На уровне фортовских определений "1 +" и "1+" не различаются. От "1+" интуитивно ожидается чуть большая скорость выполнения или чуть меньший объем сгенерированного кода, и ничего более.

RFS, замечания от Ethereal

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