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

О, да! Это одна из моих любимых фраз.

"(simple, stupid) - похоже Ваше всё" - то есть вы понимаете эту фразу именно так.
То есть вы сопоставляете простоту и глупость. Хотя смысл фразы с точность до наоборот. В ней глупость противопоставляется простоте. А для вас, значит, чем проще, тем глупее. И чем сложнее, тем для вас умнее, значит. С вами все ясно.

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

Нет, я не переходил к обсуждению соглашений о вызовах "вообще", я говорил именно о соглашениях при вызовах в ядро.

Это вы с вашими рассуждениями о сравнении эффективности "MOV r,mem" и "PUSH/POP", и о  поломках конвейера, ушли в детали оптимизации "вообще", да еще и в привязке к архитектуре x86.

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

Если мне профилировка покажет, что именно здесь узкое место, ничто не мешает мне подобные фишки в свой код включить. Только системные вызовы-то тут при чем?
А сам по себе системный вызов "блокирующим" по-вашему не является?
Вы ранее сами говорили про переключение контекста.

У вас что, код состоит из одних системных вызовов, что для вас это так критично?
Если у вас слишком много системных вызовов, значит это уже не прикладной код, и проще уже его вставить в ядро в виде модуля и не париться.

Обычно, наоборот, оптимизация как раз и заключается в организации обработки данных таким образом, чтобы количество системных вызовов как можно более сократить.

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

Ну, сообщит, значит еще лучше. И что?
Вот именно, что вы слишком верите оптимизаторам, что они вам заранее все предскажут, и как видно не любите пользоваться профилировщиками. Потому что профилировка требует аналитических способностей, а не просто зазубривание рецептов и пихание их везде, где надо и не надо, ценой усложненния кода. Если рецепт в одном случае хорошо себя проявил, это не значит, что он даст такие же показатели во всех случаях.

А если вы сами ассемблерный код не пишите, а пользуетесь исключительно оптимизаторами, то вы вообще эту разницу не почувствуете, как именно производятся системные вызовы.

Вы конечно опять назовете меня К.О., и задним числом заявите, что вы это все и раньше якобы знаете. Однако все же замечу, что профессиональная (нерецептурная) оптимизация делается по-другому.
Сначала создается простой и правильный код без оптимизаций. Потом профилировкой выясняются узкие места. Сокращаются временные характеристики алгоритмов O[f(n)]. А описанные вами проблемы, связанные с задержками памяти по отношению к регистрам - это всего лишь линейный множитель к общему времени работы алгоритма. А это все оптимизируется в последнюю очередь.

Бездумно вставляя рецепты по оптимизации ценой усложнения кода, вы лишь отрубаете себе возможность оптимизировать код в дальнейшем, когда это будет действительно нужно.

Вы просто не знаете, что такое UNIX, зачем это создавалось и в каких средах работает.
И узким местом являются там каналы передачи данных и межпроцессное взаимодействие, и уж точно не быстродействие памяти. И приоритетом в Юниксах являются надежность, правильность и безопасность, а уж потом только скорость.

А вы своими рассуждениями, лишь уточнили ту целевую аудиторию, для которой DOS/Linux предназначен.

>> Т.е. рассуждая о всяких там кешах, очередях и регистрах в современных процах,
>> вы по прежнему убеждены, все эти технологии обошли стек стороной.
>
> Ну так пруф где?
> Резюме: привести пруф за 3 сообщения не удосужился, слив защитан.

Если ничего этого нет, то это мой слив.
А если это есть, значит вы просто находитесь во власти стереотипов.

Еще одна подсказка вам: попробуйте посмотреть на процессор и стек не с точки зрения стереотипов того ассемблера, к которому вы привыкли, а еще и с точки зрения самой схемотехничекой и математической сути этих артефактов (т.е. созданных людьми технологий и предметов).