>> +; Переход никогда не происходит. Предотвращает предсказания следующего
>> +; косвенного перехода, во многих случаях некорректные.
> На всякий, это давно не так.У меня про данный частный случай. В цитате выше я восстановил комментарии, закрытые в исходном сообщении звёздочками.
execute_instruction:
mov eax, [opcode]
shl rax, instruction_size_log2
+; Переход никогда не происходит. Предотвращает предсказания следующего
+; косвенного перехода, во многих случаях некорректные.
+ jc .stop
lea rax, [rax + vm_base + vm_base_lbl - execute_instruction]
next_opcode
jmp rax
- ud2
+.stop: ud2
> "Не переход" является таким-же учетным фактом как и "переход" для подавляющего большинства
> предсказателей, т.е. почти для всех актуальных ЦПУ с предсказателями (не только
> штеудовских ядер).
В данном случае процессор не знает значение opcode, потому предполагает возможность перехода и видит его целью ud2.
Я наивно последовал правилу:
Assembly/Compiler Coding Rule 14. (M impact, L generality) When indirect branches are
present, try to put the most likely target of an indirect branch immediately following the indirect
branch. Alternatively, if indirect branches are common but they cannot be predicted by branch
prediction hardware, then follow the indirect branch with a UD2 instruction, which will stop the
processor from decoding down the fall-through path.
но без "неперехода" предиктор упорно заставлял процессор начинать исполнять следующую после ud2 команду.
Может быть там надо было два раза подряд ud2 поставить, как в том анекдоте, но у меня не стояла задача оптимизировать, потому не разбирался в деталях. Надо было проверить пару гипотез, для чего пришлось переписать с Си на асм (таблицу переходов выкинул - это не оптимизация, а упрощение кода). Когда в итоге код на асме заработал вдвое медленнее, пришлось дотягивать его до уровня компилятора.
> Упрощенно, предсказывается не факт перейдем/не перейдем, а адрес перехода (как вариант
> в координатах uops-кеша), а по факту корректируется статистика угадали или нет+актуальный_адрес.
Да, тут игнорируется расширение нулями 32-разрядного eax (что гарантирует неисполнение перехода), либо ud2 имеет приоритет, как команда остановить декодирование.
>[оверквотинг удален]
> начинать фрагмент с перехода, которому не нужна история, т.е. с добавленного
> патчем jc.
> Далее, в реальном коде загрузка опкода в регистр будет с дополнением нулями.
> Соответственно, CF всегда и гарантированно будет 0. Подобные ситуации используются штеудом
> для реализации "косвенного управления" (при трансляции инструкций в uosp участвует микрокод,
> который детектирует подобные паттерны и вставляет отдельные специфические uops-команды
> в конвейер).
> Так вот, весьма вероятно, что использованный паттерн либо генерирует upos отключения предсказателя
> для следующего перехода, либо подсказывает поставить pivot point для отметки начала
> фрагмента для накопления статистики переходов.
Так и как писать на ассемблере? Это лишь малая часть необходимых знаний, что бы обогнать транслятор. Оратор, кому я отвечал, утверждал, что это элементарно. Мне пришлось когда-то посидеть с AMD CodeAnalyst, где проводилась симуляция конвейера и микрооперации можно было увидеть глазами, потому на автомате могу написать получше некоторых, и то сел в лужу.)
Разве что в образовательных целях писать: у AMD64 достаточно регистров, системные вызовы в Linux проще любимого некоторыми DOS-а, нет бестолковой возни с сегментами.
> С одной стороны, погружение в подобные тонкости может показаться интересным. Но как
> уже писал, мне это уже давно представляется "штопаньем чужих носок", вместо
> того чтобы делать что-то собственное.
Я узнал, что у Эльбруса отдельный стек для адресов возвратов, и задумался, как ещё возможно использовать стек данных. Проверил подручными средствами, реализовал стековую виртмашину, использовав аппаратный стек. На AMD64 пришлось всё затолкать в один стек, но сработало. На Эльбрусе, наверное, красивее должно смотреться, если бы к языку типа Си добавить возможность работать со стеком явно.
