Why Plan 9 C compilers don't have asm("")
Quoted 14 lines
Quoted 1 line
Cort Dugan
Quoted 11 lines
There isn't such a crippling difference between straight-line and code with>
unconditional branches in it with modern processors. In fact, there's> very
little measurable difference.If you're looking for something to blame hurd performance on I'd suggest
the entire design of Mach, not inline asm vs procedure calls. Tossing a
few context switches into calls is a lot more expensive.
hpa
Quoted 5 lines
That's not where the bulk of the penalty of a function call comes in (and it's a call/return, not an unconditional branch.) The penalty comes in because of the additional need to obey the calling convention, and from the icache discontinuity.
call/return is two unconditional branches and a push and a pop (is that right?), which is I think what CD means, i.e. in terms of branch prediction. The push/pop is a hit on old CPUs, donno about >386. You're right though. The big hit is you can't lose the pushes to set up the args for a separately assembled function, or the frame drop that follows it.
Quoted 2 lines
Not to mention that certain things simply cannot be done that way.
Don't tell me that. Then I can't use my subroutine-threaded Forth variant, in which + is a subroutine call. ;o)
Anyway, yes it's a performance hit to not inline asms. Is it worth the bletchery? It's worth asking that once in a while. I've looked at set_bit both ways. Now I'm curious how it does as straight C.
Rick Hohensee