>  I'd guess it's more likely because NetBSD has all the ABI overhead,
>which Ultrix probably doesn't have.  That makes the programs bigger and
>slower.

Yup. I think we (I?) estimated a 10% slowdown when we decided to go to
ELF and to use the standard ABIcalls for "statically linked" binaries.


Mika's numbers and observations from about 3 weeks ago were pretty
convincing.  That specific problem is, basically, that the ABI-call
machinery (.cpsave/.cprestore) is handled in the assembler as
pseudo-ops, and the assembler doesn't seem to do any scheduling at all
on the loads and stores those pseudo-ops generate. So it emits nulls
around them, slowing down calls.

I thought about trying to emit the $t9 manipulations directly from GCC
as RTL and having GCC schedule them.  But that'd run foul of the
PIC-must-use-abicall warnings which're built into gas. Getting gas to
schedule the .cpsave/.cprestore loads better might be best.  Anyone
care to look at how a IRIX toolchain schedules .cpsave/cprestore on
Mika's example?

(I dont want to start supporting non-abicall libraries; that'd mean a
brand-new library suffix, gcc/specfile changes, etc. Not nice.  But if
Simon wanted to try it, that'd quantify the cost pretty precisely.)