[lkml]   [2001]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
>Cort Dugan
>> There isn't such a crippling difference between straight-line and code
>> unconditional branches in it with modern processors. In fact, there's>
>> little measurable difference.
>> If you're looking for something to blame hurd performance on I'd
>> the entire design of Mach, not inline asm vs procedure calls. Tossing
>> few context switches into calls is a lot more expensive.
>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.

>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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:56    [W:0.026 / U:1.520 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site