> Вы видимо не знаете более достойного использования регистровВ момент вызова ядра более достойного использования им всё равно нет - все придется сохранять.
Суть проста: процедуры в ядре для работы используют что? Регистры! Поэтому хоть так, хоть эдак - а сохранять их перед вызовом придется. Т.е. раз так и так сохранять - зачем делать двойную работу? Пусть софт (к которому имеет доступ оптимизатор) сохраняет только нужные регистры. Вполне грамотный подход. В x86_64, кстати, ядро разрушает не все регистры.
> Подсказка - учтите соотношение времени жизни параметров процедур и время жизни других
> структур данных в современных программах.
Учел. "Структуры данных" на регистры не размещаются, поэтому мимо тазика. А поинтеры можно и перезагрузить.
> Вторая подсказка - учитывая вами же высказанное соотношение скорости доступа к регистрам и к памяти - если вас волнует быстродействие, следует посчитывать все
> вычисления в программе, а не только вызовы процедур.
Балалайку о неоптимальности регистровых вызовов завели вы. Я вам указал на то, что регистровые вызовы оптимальнее стековых, если возможны. Причем во всех ипостасях. По сравнению даже с INT/SYSCALL вся эта чехарда с регистрами - мелочь.
> Если уж речь зашла именно о современных процессорах, то вы видимо не
> знаете об аналогичных "хитростях" при работе со стеком.
Примеры в студию :)
> Т.е. на той стороне вы уже имеете оптимизированный код, к которому
> ваш любимый оптимизатор доступа не имеет.
В данном случае поведение "той стороны" абсолютно не критично. Оптимизировать надо сохранение регистров на стороне caller, и все оптимизаторы это умеют.
> Ну и напоследок, ассемблерный код с передачей параметров через стек - более
> нагляден, и его легче отлаживать.
Дело привычки, не более. А код, генерируемый современными компиляторами, отлаживать трудно хоть так, хоть эдак. Более того (открою страшную тайну) - GCC в ряде случаев может использовать регистровые вызовы для оптимизации.
