xacquire/xrelease являются просто префиксами REP F2 / F3 и безопасно игнорируются всеми процессорами, которые не поддерживают эту функцию , включая не Intel. Вот почему Intel выбрала эту кодировку для префиксов. Это даже лучше, чем NOP, который должен декодироваться как отдельная инструкция.
В общем случае (у разных поставщиков) процессоры игнорируют префиксы REP, которые они не понимают. Таким образом, новые расширения могут использовать REP как часть их кодирования, если для них полезно декодировать как-то еще на старых процессорах, вместо #UD.
Я не думаю, что AMD может ввести несовместимое значение для префиксов rep на lock ed инструкции или mov-store - это сломало бы реальные двоичные файлы, которые уже используют эти префиксы Например, я уверен, что некоторые сборки libpthread в основных дистрибутивах GNU / Linux использовали это для включения аппаратной блокировки блокировки и не используют динамическую диспетчеризацию c CPU для запуска другого кода, основанного на CPUID.
Использование REP в качестве обязательного префикса для новой инструкции обратного сжатия было выполнено до , например, с rep nop = pause или rep bsf = tzcnt. (Полезно для компиляторов, потому что tzcnt быстрее на некоторых процессорах и дает тот же результат, если входные данные известны как ненулевые.) И rep ret в качестве обходного пути для предикторов AMD для предбульдозерных ветвей широко используется G CC - Что означает `rep ret`? . Этот бессмысленный REP определенно работает (беззвучно игнорируется) на практике на AMD.
(Обратное значение не true. Вы не можете написать программное обеспечение, которое рассчитывает на бессмысленный префикс REP, игнорируемый future CPU. Некоторое более позднее расширение может придать ему значение, например, как rep bsr, которое работает как lzcnt и дает другой результат. Вот почему Intel документирует эффект бессмысленных префиксов как «неопределенный». )
Я бы хотел улучшить его, используя префиксы Intel TSX, в частности XACQUIRE и XRELEASE.
К сожалению, обновления микрокода, по-видимому, отключили HLE (аппаратная блокировка Elision) часть TSX на всех процессорах Intel . (Возможно, для смягчения атак по боковому каналу TAA ). Это было то же самое обновление, которое сделало jcc в конце 32-байтового блока недоступным для кэширования в кэше UOP, поэтому по бенчмаркингу существующего кода трудно определить, какое влияние оказывает перфорированная часть без HLE.
https://news.ycombinator.com/item?id=21533791 / Устранена ли проблема с аппаратной блокировкой навсегда из-за смягчения действия Призрака? (да, но нет, вероятно, причина не в Призраке конкретно. IDK, если он вернется. )
Если вы хотите использовать аппаратную транзакционную память на x86, я думаю, что ваш единственный вариант - RTM (xbegin / xend), другая половина TSX. Операционные системы также могут отключить его после последнего обновления микрокода; Я не уверен, что по умолчанию для типичных систем, и это может измениться в будущем, так что это что-то проверить, прежде чем вкладывать время разработки во что-либо.
Там нет AFAIK способ использования RTM, но прозрачно возвращается к блокировке; xbegin / xend - недопустимые инструкции, которые выдают ошибку #UD, если отсутствует бит функции CPUID.
Если вы хотели прозрачного обратного сжатия, вы должны были использовать HLE, так что это настоящий позор (и TSX в общем) переживал такие тяжелые времена, постоянно отключаясь из-за обновлений микрокода. (Ранее в Haswell и Broadwell из-за возможных ошибок правильности. Это превращается в Charl ie Brown ситуацию .)