Comments 21
Для некоторых из подобных команд у компилятора могут быть интринсики, что может быть удобней в плане программирования.
да, но надо иметь в виду, что вызов каждого интринсика это еще и накладные расходы на подготовку регистров с операндами (или стекового кадра).
Если производительность не критична, то можно пользоваться интринсиками, чтобы все равно будет быстрее лутов и циклов, особенно если луты должны быть большими.
Насколько медленнее/быстрее будет подобный инлайн?
asm("rbit %0,%1" : "=r" (buf[i]) : "r" (buf[i]));
asm("rev %0,%1" : "=r" (buf[i]) : "r" (buf[i]));
Иногда компилятор все же умнее
https://godbolt.org/z/Tc5aerW7a
вызов каждого интринсика это еще и накладные расходы на подготовку регистров с операндами
Грамотная реализация intrinsics подразумевает, что они описываются в тех же таблицах, что и обычные процессорные операции. Если оптимизатор не совсем тупой - подберет регистры так, чтоб не гонять туда-сюда.
или стекового кадра
Зачем для intrinsic стековый кадр? У ARM есть команды, работающие только над кадром?
Сдаётся мне, что контроллер [дисплея] имеет возможность аппаратно настраивать порядок связи пикселей с битами.
Шрифт - вырвиглазомозг, 145%.
P.S. Не рассмотрен ещё "алгоритмический трюк" по реверсу битов вместо таблицы. Не разбирался, что там за магия с константами, но он - работает.
Специально ещё раз посмотрел датащит на ssd1309 и там есть только ремап колонок, но не битов относительно пикселей.
А по поводу шрифта могу сказать только то, что перебрал очень много разных шрифтов. Именно этот наиболее сильно работает на погружение в устройство. Если людям нужен таймс нью роман, они используют Аблетон.
И да, шрифт на 145% вырвиглазмозг в первые пять минут работы, а потом нормально адаптируется и совершенно не замечает.
RBIT - берет слово и возвращает за один цикл процессора число с обратным порядком битов.
REV - берет слово и возвращает за один цикл процессора слово с обратным порядком байтов.
Касаемо REV я понимаю: можно менять тупоконечный формат на остроконечный и обратно. Касаемо RBIT не понятно: у вас по тексту меняется порядок битов в слове, т.е. D0 обменивается с D31 и т.д., но тогда последующий REV как бы и не нужен. Хотя вот в доке так описано:
Меня как то занимал вопрос почему в x86 на асме есть инструкции ror/rol, даже в Паскале есть, а в С/С++ нет и нужно корячиться с двумя сдвигами и лог.сложением
И к какому выводу вы пришли?
Если использовать конструкцию в виде одной длинной строки, то компилятор Clang всё таки её превращает в rol/ror, поэтому просто имею файл с набором подобных макросов
Но сама ситуация не нормальная, при работе с некоторыми устройствами и криптографией очень полезная штука
Что касается циклического сдвига в ЯВУ вообще прям беда да. Только арифметические.
Заметьте в Паскале это работает, не нужно писать три операции, не нужно писать свои версии для каждой разрядности передаваемого типа, работает само, почему они не могут это внести в Си я не понимаю.
Впрочем нужно шагать в ногу со временем, в Rust таки эти операции появились, пусть через метод, но всё же в явном виде
Можно же сделать ассемблерную вставку с нужной операцией.
Можно, но это, по меньшей мере, непереносимо, так как: а) зависит от компилятора (как там оформляются ассемблерные вставки), и б) от архитектуры процессора (одна и та же операция на IA-32, ARM и RISC-V должна быть оформлена по-разному). А вот включение соответствующей операции в сам язык высокого уровня делает эту операцию стандартной и переносимой без лишних проблем.
Чем не устраивает std::rotl и std::rotr?
У меня сразу ассоциации с sunvox'ом, с которым мне одно время нравилось играться. Очень интересно наблюдать за тем, как музыка, математика и программирование взаимодействуют)
Использование Assembler'a. Фишка 1