thru carry
Nov. 7th, 2014 08:57 pmМини-квест для пользователей десктопов и лаптопов, в общем, x86: найдите хоть одну команду RCL или RCR в естественно возникшем (из пакетов, etc.) программном коде на своей системе. Ложные срабатывания (показ мусора как кода в mplayer, libavcodec) не в счёт.
У меня пока что результат - только libgmp с куском хитрой арифметики (__gmpn_rsh1add_n, __gmpn_rsh1sub_n и тому подобные), причём там сдвиги ровно по 1 биту, и libgcrypt (в OpenSuSE), с каким-то бешеным алгоритмом, аналогично.
UPDATE[2016.08.23]: RCR была бы полезна для небольших упрощений деления на 7, 19 и т.п., там, где сейчас борются с беззнаковым переполнением через промежуточные короткие результаты.
У меня пока что результат - только libgmp с куском хитрой арифметики (__gmpn_rsh1add_n, __gmpn_rsh1sub_n и тому подобные), причём там сдвиги ровно по 1 биту, и libgcrypt (в OpenSuSE), с каким-то бешеным алгоритмом, аналогично.
UPDATE[2016.08.23]: RCR была бы полезна для небольших упрощений деления на 7, 19 и т.п., там, где сейчас борются с беззнаковым переполнением через промежуточные короткие результаты.
no subject
Date: 2014-11-10 01:31 pm (UTC)Я думаю, было, иначе было невозможно организовать даже включение 32-битного режима. И вообще, выполнять только часть операций в 32, остальные в 16 - это активно использовалось (например, была сборка MultiEdit для 386-го процессора, сильно быстрее обычной).
> Но тогда пришлось бы на кристалле размещать еще один декодер для совместимости со старым 16-битным кодом.
Для некоторых из этих переходов новый декодер можно было бы отложить. Например, реально не отменяя некоторые коды сразу в 386, а только когда они понадобятся. Аналогично с удлинением - если потребовать некоторый префикс только для 32, а реально поддерживать и для 16. В общем, захотели бы сделать с умом - сделали бы. Обидно именно то, что желания не было.