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

Ethereal

Ежели есть набросок стандарта, дык надо его реализовать и посмотреть что получится.
Начал приводить свой форт к рекомендации от RFS и тут-же напоролся.

В наброске RFS сказано :
2/ - разделить верхний элемент стека на два
D2/ - разделить верхний двойной элемент стека на два

Дык неправильно это !

Объясню почему. Берем всеми любимый SPF и начинаем :

-3 2/ .
-2  Ok
-3 2 / .
-1  Ok

Результат выходит разный.
Ну и какое из этих двух действий было делением верхнего элемента стека на два, а какое не было ?

Вообще-то были оба. Только 2/ - это было деление с округлением по полу, а 2 / -
было симметричное деление (так инструкция IDIV от 80x86 делит). Ну нельзя в одном
и том-же стандарте под делением подразумевать не пойми что. Либо в стандарте
нужно провозгласить, что одна и та-же форт система может делить по разному
зависит от того как и чем поделишь (2/ - одним образом, а 2 / - другим), либо обозвать
/ - собственно делением, а 2/ - сдвигом с распространением знака и лишь в скобках
дать этому сдвигу второе толкование - (деление на два с округлением по полу).

white_TigR

Ethereal писал(а):

В наброске RFS сказано :
2/ - разделить верхний элемент стека на два

Всегда считал, что это SHRA - арифметический сдвиг вправо.

chess

white_TigR писал(а):

Всегда считал, что это SHRA - арифметический сдвиг вправо.

Да так и есть, на один разряд вправо с сохранением старшего разряда.
2/ и 2 / выглядят одинаково, что и могло привести в заблуждение первописателей RuFS.

dynamic-wind

Так лучше обобщить 2/ и 2* до сдвигов >> и << на любое число бит.
Тогда и вопросов не будет, и появится быстрая операция умножения-деления.

chess

dynamic-wind писал(а):

Так лучше обобщить 2/ и 2* до сдвигов >> и << на любое число бит.
Тогда и вопросов не будет, и появится быстрая операция умножения-деления.

Можно, например в spf, уже есть ARSHIFT, не помню есть-ли ALSHIFT, но легко можно ввести.
У меня встроенный ассемблер, поэтому всегда можно по случаю быстро все 'недостающее' ввести.
Вот если бы не было ARSHIFT, ALSIFT, то:

Код:

: >> ( N n -- 'N ) C=A A=@P Aa>>  $ 4 Pa  ;
: <<  ( N n -- 'N ) C=A A=@P Aa<<  $ 4 Pa  ;     

chess

chess писал(а):

не помню есть-ли ALSHIFT, но легко можно ввести

Посмотрел на код >> и << :

Код:

: >> ( N n -- 'N ) C=A A=@P Aa>>  $ 4 Pa ;  SEE >>
: << ( N n -- 'N ) C=A A=@P Aa<<  $ 4 Pa ;  SEE <<

лог

Код:

CODE >>
5D06D3 8BC8             MOV     ECX , EAX
5D06D5 8B4500           MOV     EAX , 0 [EBP]
5D06D8 D3F8             SAR     EAX , CL
5D06DA 8D6D04           LEA     EBP , 4 [EBP]
5D06DD C3               RET     NEAR
END-CODE
( 11 bytes, 5 instructions )


CODE <<
5D06EF 8BC8             MOV     ECX , EAX
5D06F1 8B4500           MOV     EAX , 0 [EBP]
5D06F4 D3E0             SHL     EAX , CL
5D06F6 8D6D04           LEA     EBP , 4 [EBP]
5D06F9 C3               RET     NEAR END-CODE
( 11 bytes, 5 instructions )

 Ok

Оказывается код SAL и SHL (ариф. сдвиг влево и лог. сдвиг влево абсолютно одинаковы)
Теперь понятно почему в spf нет ALSHIFT, оно абсолютно тоже что и LSHIFT.

_Harry

chess писал(а):

Теперь понятно почему в spf нет ALSHIFT, оно абсолютно тоже что и LSHIFT.

Величайшее открытие :hey;

Может стоило сначала почитать , хотя бы в википедии, про сдвиги, а заодно и про проблемы целочисленного деления :?:

.

chess

_Harry писал(а):

Величайшее открытие Может стоило сначала почитать , хотя бы в википедии, про сдвиги, а заодно и про проблемы целочисленного деления .

Не пользовался арифметическим сдвигом влево.
Зачем читать, когда за минуту можно узнать из своего форта.

Hishnik

chess писал(а):

Зачем читать, когда за минуту можно узнать из своего форта.

Хотя бы затем, чтобы убедиться, что в СвойФорт оно попало в правильном варианте

Арифметический сдвиг влево можно сделать хотя бы для комплектности.

mOleg

Ethereal писал(а):

В наброске RFS сказано :
2/ - разделить верхний элемент стека на два
D2/ - разделить верхний двойной элемент стека на два

дык, атавизм это. С тех времен пошло, когда операция деления была медленной, а деление на два было удобно реализовывать, как отдельный примитив. Сейчас данные операции имеют смысл только при реализации их в ядре процессора. В остальных случаях можно писать: 2 / или 2 DS/

chess

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

Хотя бы затем, чтобы убедиться, что в СвойФорт оно попало в правильном варианте

Арифметический сдвиг влево можно сделать хотя бы для комплектности.

Да это еще 3 года назад сделано с проверками, а википедия это в последнюю очередь, есть же более достоверные источники. Просто я им этим левым ар. сдвигом ни разу после не пользовался.

chess

mOleg писал(а):

дык, атавизм это. С тех времен пошло, когда операция деления была медленной, а деление на два было удобно реализовывать, как отдельный примитив.

Тут вы не правы, попрежнему сдвиг делается быстрее чем деление и ни на какие-нибудь 10%,
а примерно в 2 раза.

mOleg

chess писал(а):

Тут вы не правы, попрежнему сдвиг делается быстрее чем деление и ни на какие-нибудь 10%,а примерно в 2 раза.

И тем не менее устарело. По-нормальному, оптимизатор должен сам такие случаи "просекать"

А вот добавление лишней сущности в данном случае сейчас уже не оправдано.

WingLion

chess писал(а):

а примерно в 2 раза.

Вызов ассемблерного слова и NEXT тоже чудесно ускоряется в 2 раза?

chess

mOleg писал(а):

А вот добавление лишней сущности в данном случае сейчас уже не оправдано.

Какой сущности? Арифметический сдвиг вправо - это лишняя сущность? Вы о чем собственно?

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

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