>>>> Все нормальные юниксы передают их через стек. И только в Linux почему-то
>
> Потому, что доступ к регистрам быстрее доступа в память. А регистров на современных процах полно. Особенно на не-x86. И на x86_64. И только "нормальные юниксы" этого не учитывают, каждый вызов жертвуя пропускной способностью кеша и памяти.Вы видимо не знаете более достойного использования регистров, пусть даже если регистров большое количество, пусть даже целые регистровые файлы, - кроме как забивание их параметрами процедур.
Подсказка - учтите соотношение времени жизни параметров процедур и время жизни других структур данных в современных программах.
Вторая подсказка - учитывая вами же высказанное соотношение скорости доступа к регистрам и к памяти - если вас волнует быстродействие, следует посчитывать все вычисления в программе, а не только вызовы процедур.
>>>> Заставляя приложение все время сохранять и восстанавливать регистры и терять кучу циклов на это
> Зачем? Компилятор настолько туп, что не может оптимизировать доступ к регистрам?
Конечно он это оптимизирует, только эта оптимизация в большинстве случаев будет не в пользу процедурных параметров. А DOS^W Linux просто вынуждает забивать ими регистры при системных вызовах.
>>>> и увеличивая вероятность возникновения ошибок.
> Можно пояснить, чем разница в расположении данных "увеличивает вероятность"?
Если вы сами не отлаживали ассемблерный код, полагаетесь исключительно на генераторы и оптимизаторы, если вы занимаетесь только прикладным программированием - для вас разницы нет. А вот для тех, кто занимается разработкой компиляторов и прочих инструментов, которые вы же потом и используете, - для них разница есть. И эта разница как раз и влияет на качество тех инструментов, которые вам достаются, в том числе тех же оптимизаторов и генераторов.
>>>> Хотя регистры все равно в стек сохраняются. Зачем этот ДОС-овский маразм нужен?
> Есть хитрость - в ряде случаев можно ничего не сохранять.
Если уж речь зашла именно о современных процессорах, то вы видимо не знаете об аналогичных "хитростях" при работе со стеком.
И наконец, не забывайте, что речь шла именно о вызовах в ядро. Т.е. на той стороне вы уже имеете оптимизированный код, к которому ваш любимый оптимизатор доступа не имеет. Кроме того, учтите особенности оптимизации ядра. Ах, ну да, у вас же DOS^W Linux, с его особенностями оптимизации.
Ну и напоследок, ассемблерный код с передачей параметров через стек - более нагляден, и его легче отлаживать. Хотя конечно если вы считаете, что чем более код запутан, тем круче, для вас наверное это тоже не аргумент.
