Здравствуйте, кт, Вы писали:

кт>Ведь что получается: запускается программа. Стек у нее выровнен – как надо выровнен.
кт>Например, далее вызывается подпрограмма без параметров, а внутри подпрограммы уже вызывается API. При выполнении инструкции CALL стек автоматически меняется (сюрприз) на 8 байт и становится НЕ выровнен на 16. Т.е. при вызове API идет все время геморрой насчет кратности 16 и автоматически вам его нужной кратности никто не обеспечивает.
кт>Неужели это чудило под гордой вывеской Микрософта не догадалось, что:

Ты не поверишь — на Unix точно так же.
Соответственно даже в очень простой нелистовой функции без своих параметров в стеке — в начале идёт "sub rsp,8" (в синтаксисе Intel) и обратное восстановление на выходе.
Или же стандартная последовательность из push rbp / mov rbp, rsp. Тоже корректировка на 8.
Или push rbx.
Впрочем, если функция имеет локальные параметры в стеке, то всё равно надо заводить под них место, и эта корректировка rsp включает в себя и эти 8 байт зазора.
Это я рассматривал выхлопы GCC и Clang.

Так что — если в обоих лагерях чудилы, то это неспроста Может, они и не чудилы?

кт>2) Если приспичило сохранять XMM, то выровни ты стек ВНУТРИ API, а не заставляй это делать в тысячах мест вызовов API, неужели это не очевидно? В тысячах программ, в тысячах мест стоит это дурацкое выравнивание стека на 16 потому, что «здесь так принято».
кт>Мне кажется, в Микрософте очень мало или совсем нет людей, кто оценивает эффективность кода в целом, т.е. приложение+операционная система.

Во времена GCC 3.x так часто и делали — функция корректировала себе указатель стека через and с маской. Потом отказались.

Я думаю, в недрах тундры профильных рассылок можно найти обоснование.