thru carry

[netch80]

Мини-квест для пользователей десктопов и лаптопов, в общем, x86: найдите хоть одну команду RCL или RCR в естественно возникшем (из пакетов, etc.) программном коде на своей системе. Ложные срабатывания (показ мусора как кода в mplayer, libavcodec) не в счёт.

У меня пока что результат - только libgmp с куском хитрой арифметики (__gmpn_rsh1add_n, __gmpn_rsh1sub_n и тому подобные), причём там сдвиги ровно по 1 биту, и libgcrypt (в OpenSuSE), с каким-то бешеным алгоритмом, аналогично.

UPDATE[2016.08.23]: RCR была бы полезна для небольших упрощений деления на 7, 19 и т.п., там, где сейчас борются с беззнаковым переполнением через промежуточные короткие результаты.

Comments

[dimich-dmb.livejournal.com]

> По-нормальному для 32-битного кода нужно было сделать новый декодер

По-нормальному с технической точки зрения — безусловно. Но тогда пришлось бы на кристалле размещать еще один декодер для совместимости со старым 16-битным кодом. Кстати, интересно: возможность использования 32-битных инструкций в 16-битном режиме — это побочный эффект, или было такое требование при проектировании?
Или еще как вариант: отказаться от аппаратной поддержки 16-битного режима, но в БИОС встроить программный супервизор для эмуляции. Но тут тоже могли быть трудности, 80386 использовался не только в IBM AT c его БИОСом.

[netch80.livejournal.com]

> Кстати, интересно: возможность использования 32-битных инструкций в 16-битном режиме — это побочный эффект, или было такое требование при проектировании?

Я думаю, было, иначе было невозможно организовать даже включение 32-битного режима. И вообще, выполнять только часть операций в 32, остальные в 16 - это активно использовалось (например, была сборка MultiEdit для 386-го процессора, сильно быстрее обычной).

> Но тогда пришлось бы на кристалле размещать еще один декодер для совместимости со старым 16-битным кодом.

Для некоторых из этих переходов новый декодер можно было бы отложить. Например, реально не отменяя некоторые коды сразу в 386, а только когда они понадобятся. Аналогично с удлинением - если потребовать некоторый префикс только для 32, а реально поддерживать и для 16. В общем, захотели бы сделать с умом - сделали бы. Обидно именно то, что желания не было.

[netch80.livejournal.com]

> Но тогда пришлось бы на кристалле размещать еще один декодер для совместимости со старым 16-битным кодом.

Кстати, а ведь и так есть другой декодер. Потому что правила интерпретации mod-reg-r/m изменились полностью.
Блок разбора первого байта, по сравнению с ним и его последствиями, не такой и большой.

[dimich-dmb.livejournal.com]

Сейчас — да, но сейчас с технологией микрокодов плюс-минус еще один блок — не такая уж проблема.