В шахматных программах широко используются «битовые доски» (битборды 1, 2) для представления фигур на доске. А так же и для других игр на той же доске 8×8, и даже для карточных игр. С битбордами часто проводят различные операции, например, найти первый установленный бит или посчитать количество установленных битов. Для этих операций придумано много «хитрых» алгоритмов, а на современных процессорах некоторые из этих операций доступны в расширенном наборе инструкций. Например, popcnt, доступный в SSE4.2 ABM. Также есть пара инструкций bsf/bsr, которые доступны уже давно, но из JIT-компилятора к ним нет никакого доступа.
Конечно, всё серьёзные шахматные программы пишут на C++, но для прототипирования каких-нибудь алгоритмов хочется использовать C#, потому что я с ним лучше знаком и у меня меньше шансов выстрелить себе в ногу. Но производительность тоже не хочется терять просто так, в C/C++ интересующие нас инструкции доступны так называемые встроенные функции. Я попробовал сделать подобное решение и для C#.

^{HCF, n. Mnemonic for ‘Halt and Catch Fire’, any of several undocumented and semi-mythical machine instructions with destructive side-effects <...>
Jargon File}

В предыдущем посте я начал рассказ об областях применения ассемблера при разработке программных моделей вычислительных систем — симуляторов. Я описал работу программного декодера, а также порассуждал о методе тестирования симулятора с помощью юнит-тестов.
В этой статье будет рассказано, зачем программисту нужны знания о структуре машинного кода при создании не менее важной компоненты симулятора — ядра, отвечающего за моделирования отдельных инструкций.
До сих пор обсуждение в основном касалось ассемблера гостевой системы. Пришло время рассказать об ассемблере хозяйском.

На размышления меня натолкнула статья об использовании «странной» инструкции popcount в современных процессорах. Речь пойдет не о подсчете числа единичек, а об обнаружении признака окончания Си строки (нуль-терминированная строка).

Нуль-терминированная строка — способ представления строк в языках программирования, при котором вместо введения специального строкового типа используется массив символов, а концом строки считается первый встретившийся специальный нуль-символ (NUL из кода ASCII, со значением 0).

Для определения длины таких срок применяется стандартная функция

size_t __cdecl strlen(char const* str)

Алгоритм работы которой можно описать на языке Си как:

size_t strlen_algo(const char* str)
{
	size_t length = 0;
	while (*str++)
		length++;
	return length;
}

Посмотрим, во что его превращает компилятор MS Visual Studio 2019 community (Release, x86):

08811F7h:
mov         al,byte ptr [ecx]  
inc         ecx  
test        al,al  
jne         main+0D7h (08811F7h) 

Ни для кого не секрет, что в дотнет завезли интринсики. Я писал об этом и до того, как они появились и после. Плюс ещё посты на Хабре, например этот. И всё, казалось бы, замечательно, если бы не одно «но»: называются эти интринсики по-дотнетовски, а совсем не так как в ассемблере или C++.

Из-за этого трудно воспользоваться уже готовым векторизованным кодом, просто портировав его с плюсов. Так же тяжело будет и с адаптацией найденных на stackoverflow ответов и примеров )) Ведь для каждого вызова надо найти новое дотнетное название. А сделать это не так легко — если в MSDN искать называние плюсового интринсика, то найдутся только плюсовые статьи, и, может быть, где-то в самом конце то, что нам нужно.

Когда мне приходилось писать SIMD-код на плюсах, я пользовался очень хорошим ресурсом — officedaytime, где кратко и наглядно представлены все основные инструкции для x86-платформы. Я решил, что неплохо было бы заполучить такую шпаргалку и для дотнета.



Итак, не буду лить много воды, вот эта страница, адаптированная под netcore.

Мы живём в эпоху доминирования архитектуры x86. Все x86-совместимые процессоры похожи, но и все при этом немного отличаются. И не только производителем, частотой и количеством ядер.

Архитектура x86 за время своего существования (и популярности) пережила много крупных апдейтов (например, расширение до 64 бит — x86_64) и добавлений «расширенных наборов инструкций». К этому приходится подстраиваться и компиляторам, которые по-умолчанию генерируют максимально общий для всех процессоров код. Но среди расширенных инструкций есть много интересного и полезного. Например, в шахматных программах часто используются инструкции для работы с битами: POPCNT, BSF/BSR (или более свежие аналоги TZCNT/LZCNT), PDEP, BSWAP и т.д.

В компиляторах C и C++ явный доступ к таким инструкциям реализован через «присущие (intrinsic) данному процессору функции». пример1 пример2

Для .NET и C# такого удобного доступа не существовало, поэтому когда-то давно я сделал свою обёртку, которая предоставляла эмуляцию таких функций, но если CPU их поддерживал, то заменяла их вызов прямо в вызывающем коде. Благо, большинство нужных мне интринсиков помещались в 5 байт опкода CALL. Подробности можно почитать на хабре по этой ссылке.

С тех пор прошло много лет, в .NET нормальных интринсиков так и не появилось. Но вышел .NET Core, в котором ситуацию исправили. Сначала появились векторные инструкции, в потом и почти весь* набор System.Runtime.Intrinsics.X86.
_{* — нет «устаревших» BSF и BSR}

И всё вроде-бы стало хорошо и удобно. Если не считать того, что определение поддержки каждого набора инструкций всегда было запутанным (какие-то включаются сразу наборами, для каких-то есть отдельные флаги). Так .NET Core запутало нас ещё сильнее с тем, что между «разрешёнными» наборами есть ещё и какие-то зависимости.