>>>> Все нормальные юниксы передают их через стек. И только в Linux почему-то
>
> Потому, что доступ к регистрам быстрее доступа в память. А регистров на современных процах полно. Особенно на не-x86. И на x86_64. И только "нормальные юниксы" этого не учитывают, каждый вызов жертвуя пропускной способностью кеша и памяти.

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

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

Конечно он это оптимизирует, только эта оптимизация в большинстве случаев будет не в пользу процедурных параметров. А DOS^W Linux просто вынуждает забивать ими регистры при системных вызовах.

>>>> и увеличивая вероятность возникновения ошибок.
> Можно пояснить, чем разница в расположении данных "увеличивает вероятность"?

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

>>>> Хотя регистры все равно в стек сохраняются. Зачем этот ДОС-овский маразм нужен?
> Есть хитрость - в ряде случаев можно ничего не сохранять.

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

И наконец, не забывайте, что речь шла именно о вызовах в ядро. Т.е. на той стороне вы уже имеете оптимизированный код, к которому ваш любимый оптимизатор доступа не имеет. Кроме того, учтите особенности оптимизации ядра. Ах, ну да, у вас же DOS^W Linux, с его особенностями оптимизации.

Ну и напоследок, ассемблерный код с передачей параметров через стек - более нагляден, и его легче отлаживать. Хотя конечно если вы считаете, что чем более код запутан, тем круче, для вас наверное это тоже не аргумент.