В системе команд x86 совершенно нет команды битового разворота (в arm это называется RBIT)
— т.е. команды, которая разворачивает биты в байте или слове, ставит первый бит на последнее место, второй на предпоследнее и т.д.
В группе опкодов Unary group 3 (коды F6-F7) есть следующие команды
/0 TEST
/1
/2 NOT
/3 NEG
/4 MUL
/5 IMUL
/6 DIV
/7 IDIV
т.е. код /1 свободный. Я подумал, почему бы туда не добавить?
И в какое спортлото писать чтобы добавили?
Здравствуйте, x-code, Вы писали:
XC>В системе команд x86 совершенно нет команды битового разворота (в arm это называется RBIT) XC>И в какое спортлото писать чтобы добавили?
Потребуется доказать выгоду от включения этой команды для каких-то конкретных алгоритмов и областей применения, по сравнению с кодом типа такого.
Сейчас если что-то подобное добавляется, то только для применений типа конкретных видеокодеков, см.
например команды BEXTR, BLSI, BLSMSK, или криптографии, как для PCLMULQDQ, и выгода должна реально оцениваться десятками миллионов долларов, чтобы окупить проведение через все процедуры по вписыванию этого в процессор.
Если сможете доказать такое Intelʼу, то почему бы и нет?
Но я уверен, что они этот вопрос уже рассмотрели и закрыли.
N>Потребуется доказать выгоду от включения этой команды для каких-то конкретных алгоритмов и областей применения, по сравнению с кодом типа такого. N>Сейчас если что-то подобное добавляется, то только для применений типа конкретных видеокодеков, см.
Есть инфа что для FFT полезно: https://stackoverflow.com/questions/4245936/mirror-bits-of-a-32-bit-word
Как много веселых ребят, и все делают велосипед...
Здравствуйте, netch80, Вы писали:
N>выгода должна реально оцениваться десятками миллионов долларов, чтобы окупить проведение через все процедуры по вписыванию этого в процессор.
да ладно, наверняка для этого достаточно микрокод загрузить
Здравствуйте, mike_rs, Вы писали:
_>Здравствуйте, netch80, Вы писали:
N>>выгода должна реально оцениваться десятками миллионов долларов, чтобы окупить проведение через все процедуры по вписыванию этого в процессор. _>да ладно, наверняка для этого достаточно микрокод загрузить
Конечно, нет.
Во-первых, от загрузки микрокода никак не появится блок разворота собственно в виде вентилей, а без него смысла нет.
Во-вторых, бо́льшая часть т.наз. микрокода процессоров это не код как таковой, а параметры для служебных регистров, которыми можно регулировать "вот этот недопроверенный блок быстрого сложения исключаем, а все запросы пойдут на медленный, но уже 20 лет как безглючный" или "в такой-то комбинации параметров исключить оптимизацию".
Здравствуйте, x-code, Вы писали:
XC>т.е. код /1 свободный. Я подумал, почему бы туда не добавить? XC>И в какое спортлото писать чтобы добавили?
Надо написать в Интел, что вы работаете на АМД, и по секрету узнали, что в новом процессоре скоро появится такая команда, и аналогичное письмо написать в АМД. Очень важно не перепутать, кому вы что пишете. А то если вы напишете в Интел, что вы работаете на Интел, они сразу догадаются, что к чему, и команду не добавят.
Здравствуйте, ononim, Вы писали:
N>>Потребуется доказать выгоду от включения этой команды для каких-то конкретных алгоритмов и областей применения, по сравнению с кодом типа такого. N>>Сейчас если что-то подобное добавляется, то только для применений типа конкретных видеокодеков, см. O>Есть инфа что для FFT полезно: O>https://stackoverflow.com/questions/4245936/mirror-bits-of-a-32-bit-word
Там не просто FFT, а FFT scrambling. Это очень специфическая тема и по сравнению с прочими затратами на голосовой трафик будет просто незаметна.
Здравствуйте, x-code, Вы писали:
XC>В системе команд x86 совершенно нет команды битового разворота (в arm это называется RBIT)
А зачем она там?
XC>И в какое спортлото писать чтобы добавили?
Не добавят, скорее убирать уже пора.
Здравствуйте, CreatorCray, Вы писали:
XC>>В системе команд x86 совершенно нет команды битового разворота (в arm это называется RBIT) CC>А зачем она там?
Просто из соображений полноты. Это самодостаточная фундаментальная операция.
CC>Не добавят, скорее убирать уже пора.
Ну да, там много чего убирать пора. До сих пор есть операции двоично-десятичной коррекции. Интересно их как-то применяют сейчас?
Здравствуйте, x-code, Вы писали:
XC>>>В системе команд x86 совершенно нет команды битового разворота (в arm это называется RBIT) CC>>А зачем она там? XC>Просто из соображений полноты. Это самодостаточная фундаментальная операция.
В каком смысле "фундаментальная"?
Вот есть операции, без которых невозможно реализовать процессор. Например, по теореме Поста любую логическую операцию можно построить из NAND функций, хоть и не всегда оптимально. Из четырёх AND, OR, XOR, NOT (без констант) одна из четырёх получается из остальных трёх; неэффективно — поэтому в любом нормальном процессоре есть все четыре (с вариациями: где-то BIC aka NAND вместо AND, где-то XOR с ~0 вместо NOT, но есть).
Целочисленное сложение можно реализовать через побитовые логические операции и сдвиги; очень дорого (раз в 50 дороже прямой команды), нудно, но можно. А что даст разворот строки битов, если его можно сделать через сдвиги?
Если посмотреть на реальные архитектуры... S/360, PDP-11, VAX, 6502, MIPS, x86 — нигде нет команды разворота строки битов. ARM — есть такая команда. Но почему? А обоснование очень простое (не спрашивал, но уверен в догадке процентов на 99): они предпочли сделать RBIT и CLZ, но не CLZ и CTZ. Потому что более редкая CTZ может быть сделана через RBIT + CLZ, а заодно получаем на "вдруг пригодится". "Не пригодилась", сказал эстонец, выкидывая дохлую ворону годом спустя. Почему остальные не делают? А фиг его знает. x86 имеет BSF, BSR, LZCNT, TZCNT. Много остальных имеют тоже раздельные CLZ и CTZ (как бы ни назывались). Многие не имеют отдельной CTZ. Видимо, тоже знали, что не пригодится.
CC>>Не добавят, скорее убирать уже пора. XC>Ну да, там много чего убирать пора. До сих пор есть операции двоично-десятичной коррекции. Интересно их как-то применяют сейчас?
Что значит "до сих пор"? В 64-битном режиме их нет, опкоды вызывают ошибку.
Почему в 32-битном они до сих пор оставались — очевидно, такое вот легаси.
Почему их вообще допустили в 32-битном? Видимо, не были уверены, что станет ненужно (это ещё начало 80-х). Но там вообще упустили десятки важных шансов исправить систему команд, BCD команды тут только частная мелочь.
Здравствуйте, vsb, Вы писали:
vsb>А зачем тебе битовый разворот в процессоре? Вот тебе код на Kotlin. Пользуйся.
vsb>n.toString(2).padStart(8, '0').reversed().toInt(2)
И приз дня — копролитовая статуэтка Индры уезжает в город...
Здравствуйте, x-code, Вы писали:
XC>Ну да, там много чего убирать пора. До сих пор есть операции двоично-десятичной коррекции. Интересно их как-то применяют сейчас?
Применяют и всегда применяли для "экономических" расчетов.
Здравствуйте, netch80, Вы писали:
vsb>>n.toString(2).padStart(8, '0').reversed().toInt(2)
N>И приз дня — копролитовая статуэтка Индры уезжает в город...
Здравствуйте, кт, Вы писали:
кт>Применяют и всегда применяли для "экономических" расчетов.
В x86 никогда не применяли, это рудимент 8080 притащенный в x86 по ошибке. Нужен кому-то ли оно было в 8080 В IBM-360 оно было притащено для точной эмуляции специализированных "экономических" машин предыдущих моделей.
Здравствуйте, pagid, Вы писали:
P>В x86 никогда не применяли, это рудимент 8080 притащенный в x86 по ошибке.
IBM со своими компиляторами PL/I смотрит на Вас с недоумением. А в 8080 никаких двоично-десятичных команд (кроме одной, как раз, рудиментарной) не было. Они впервые появились в 8086 и безо всяких ошибок.
Здравствуйте, кт, Вы писали:
кт>IBM со своими компиляторами PL/I смотрит на Вас с недоумением.
PL/I — большой пыльный мешок со всеми языковыми конструкциями и типами данных до которых додумались к началу-середине 60-х. Двоично-десятичная арифметика там для эмуляции один-в-один возможностей "экономических" машин предыдущего поколения, которые в свою очередь эмулировали электро-механические табуляторы.
кт>А в 8080 никаких двоично-десятичных команд (кроме одной, как раз, рудиментарной) не было.
Вот она и была.
кт>Они впервые появились в 8086 и безо всяких ошибок.
Ошибкой было их появление, по причине ненужности.
Хотя возможно когда приступали к проектированию 8086/88 его рассматривали в том числе как основу для микрокалькуляторов, с чего собственно вся серия начиная с 4004/4040/8008 и начиналась
Здравствуйте, netch80, Вы писали:
vsb>>n.toString(2).padStart(8, '0').reversed().toInt(2)
N>И приз дня — копролитовая статуэтка Индры уезжает в город...
Шивы же. Там много рук.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, pagid, Вы писали:
P> Двоично-десятичная арифметика там для эмуляции один-в-один возможностей "экономических" машин предыдущего поколения, которые в свою очередь эмулировали электро-механические табуляторы. P>Хотя возможно когда приступали к проектированию 8086/88 его рассматривали в том числе как основу для микрокалькуляторов, с чего собственно вся серия начиная с 4004/4040/8008 и начиналась
Понятия не имею, что такое "экономические" машины. И никто не рассматривал дорогие тогда 8086 для применения в микрокалькуляторах, для этого с лихвой хватало дешевых 4004.
А данные команды обеспечивают точные (без округлений ) расчеты для данных, представленных в виде десятичных дробей и происходят от требований к вычислениям в Коболе. Поэтому в 8086 они были введены как поддержка языков высокого уровня (Кобола и PL/1), наряду с поддержкой обработки строк ("цепочечные" команды).
Здравствуйте, кт, Вы писали:
кт>Понятия не имею, что такое "экономические" машины.
Например, IBM 140x
кт>И никто не рассматривал дорогие тогда 8086 для применения в микрокалькуляторах, для этого с лихвой хватало дешевых 4004.
Для того, чуть после стало называться инженерным калькулятором не хватит. И 8008 был для того же сегмента, 8080 был его развитием, и для 8086 возможности в этом направлении расширили, благо технологии позволяли делать это уже не особо экономя на таких мелочах. Разумеется, 8086 не был процессором для калькуляторов (по цене), но возможности в этом направлении предыдущих серий покрывал полностью.
кт>А данные команды обеспечивают точные (без округлений ) расчеты для данных, представленных в виде десятичных дробей
Они не менее и не более точные, чем банальные int32 или int64 с учетом масштабирования (единица — копейка или доля копейки, чьей душе это угодно), но при этом на порядки более медленные. И как только приходится применять операцию деления в том и другом случае эта "точность" мгновенно испаряется.
кт>Поэтому в 8086 они были введены как поддержка языков высокого уровня (Кобола и PL/1), наряду с поддержкой обработки строк ("цепочечные" команды).
Реализация PL/I на 86 это дело энтузиастов и любителей, с Коболом , но сложилось впечатление, что последние десятилетия и его гоняют исключительно на старых майнфреймах, их воплощениях на современном железе, по сути аппаратных эмуляторах и возможно уже на программные перешли.