Hi Jonathan,
   I thought you might be interested in knowing this...  Dhrystone
runs at 30,303 dhrystones per second (17.2 VAX MIPS) with the 1.3
toolchain, without the abi stuff it does 38,000 dhrystones per
second (21.6 VAX MIPS), on a 25 MHz Maxine.  The fairly large
performance difference seems to be due to the fact that the abicall
instructions are generated from macros by the assembler, so they
are not subject to any compiler optimizations (there's a lot of
dead abicall code).  Also, for our architecture (although perhaps
less important for a real MIPS), the sequence

lw $somereg
nop
jalr $somereg
nop

that is generated causes problems.  Since it is an assembler
macro, the lw isn't moved forward as the compiler would.... we
see problems specifically when you have the sequence (as you 
might in a function call)

sw <something on stack>
sw <something on stack>
sw <something on stack>
sw <something on stack>
...
<above sequence>

because the lw causes (on our architecture) an equivalent of the
MIPS write buffer to be flushed (partially) before actually
executing the jalr.  On a normal MIPS, this would happen if the lw
missed in cache, too (at least, I don't know if it could have
a similar impact if it were a cache hit).  The extra indirections
will undoubtedly cost more, proportionally, on a more modern design
(such as ours) than on the 25 MHz machine due to the extra memory 
references.  (In case there's any confusion about the matter,
the Maxine on which I took the performance numbers I mentioned 
has a perfectly normal R3000 in it, the architecture I'm talking 
about is only being simulated right now.)

All this being said, it's nice to be able to fit NetBSD+X in less
than 200 MB :)


   Mika

Jonathan Stone writes:
>
>[ trying to build binaries without MIPS abicall indirection]
>
>>Trying (for instance) -G8 tells you that PIC is the default, and it
>>still produces the PIC stuff.  Adding -mno-abicalls works fine, for
>>the compilation phase, but the linker warns about linking PIC and
>>non-PIC code, and hello, world! segfaults as a result... (statically
>>linked)
>
>>Anyone want to explain what's going on or offer suggestions?  
>>Do I have to build some non-PIC'd libraries?
>
>Yes, you do.  
>
>The standard ``non-PIC'' libraries acutally have, and require, all the
>PIC indirection goo.  Otherwise, users would have to use different
>compilation flags for their own .o flags, depending on whether they
>wanted static or dynamically linked binaries.
>
>I polled the users and other NetBSD developers, and checked out what
>other MIPS-cpu systems with shared libs did, and there was a very
>strong consensus that the current behaviour was the right tradeoff.
>
>It does mean you need to rebuild all your own libraires if you want to
>shave off all the ELF PIC overhead, though.