> Значит для вас не имеет. Я уже понял, что вы предпочитаете сохранять
> регистры, не доверяя это ядру, хотя оно это и так делает.
> А потом рассуждать об оптимизации.

Я доверяю ABI, которое однозначно говорит, что надо сохранять. Нормальный оптимизатор переименует регистры перед вызовом. Хотя в случае вызова ядра любая оптимизация смысла не имеет.

>> на динамически распределенную - MOV r,mem, если же структура вся помещается на стеке - никакой перезагрузки не нужно.
> Ну а здесь какой выигрыш? В итоге та же память, тот же стек.

MOV [base+offset],imm - очень неприятная с точки зрения исполнения операция - мало того, что задействуется расчет смещения совместно с доступом в память по расчитанному оффсету (что само по себе уже задница при конвееризации) - так еще и очень длинная команда, декодеру тоже придется несладко. MOV r,imm / MOV r,mem - гораздо выгоднее. Или предлагаете последовательные PUSH imm / PUSH mem для вставки операндов использовать? В x86-архитектуре оные являются блокирующими.

Опять же - в случае вызова ядра это бессмысленно. Но мы уже перешли к обсуждению плюсов и минусов конкретной calling convention.

> Убирая из стека в регистры одно, вы будете вынуждены класть туда другое.

В том и фокус - что в стек ничего не кладется, и из стека ничего не убирается. А регистры придется сохранять даже при передаче параметров через стек. Либо ядру, либо прикладному ПО. Секрет: при передаче параметров через регистры в стек нужно сохранять меньше данных, и перезагрузка выполняется не со стека, а через imm/mem - как уже говорил - эти операции как минимум на x86 оптимальнее.

> В "наших" системах это называется "Keep it simple, stupid!".

Прикладной уровень амёбы (simple, stupid) - похоже Ваше всё :) Слишком любите эту фразу.

> Т.е. вы искренне верите, что ABI сообщит вам все варианты ветвления кода

Я верю, что ABI сообщит генератору кода, что надо сохранять, а что нет - и ядро будет следовать ABI. Как уже вами говорилось - ядру надо верить.

> И зачем? Когда ядро все равно в рантайме сохраняет нужные регистры по мере необходимости. Все просто.

Передача параметров на регистрах позволяет не сохранять их дополнительно во время работы процедуры, если это не заявлено ABI специфично. Меньше мертвого груза - меньше обращений в память.

> Это вы берете на себя ответственность утверждать, что можете лихо контролировать очередь на этапе компиляции.

На этапе компиляции как раз таки делаются оптимизации выполнения. При вызовах в ядро это не критично, но вот при вызовах в пределах одной программы...

>> Конечно дает. Особенно при инклюзивных кешах, когда любая запись в стек пролетает несколько уровней кеша, и очередь встает колом из-за ожидания доступа в память.
> Т.е. вас как-то от этого спасает сохранение регистров в тот же самый
> стек, да еще и дважды (когда это и так делает ядро).

Взгляните вот сюда - поймете.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6...

> Т.е. рассуждая о всяких там кешах, очередях и регистрах в современных процах,
> вы по прежнему убеждены, все эти технологии обошли стек стороной.

Ну так пруф где?

Резюме: привести пруф за 3 сообщения не удосужился, слив защитан.