[lkml]   [2003]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: any chance of 2.6.0-test*?
Hash: SHA1

Naturally. Evaluate the assembler when it's done. Normally an
unconditional jump takes less cycles than a conditional jump. It's hard
to argue with that. Use the right tool for the job. If the code
expression necessitates a goto within a block of code to keep things
neat and orderly, then do it.

Regarding the if () { ... }, there are no braces around the assembler
code. It's all a matter of linear instructions with jumps. An if() {
... } is a prettiness for our human eyes to organize code.


Rob Wilkens wrote:

>On Sun, 2003-01-12 at 14:58, David Ford wrote:
>>The horrific response to the use of "goto" is deprecated in favor of
>>proper use. A function overloaded with gotos probably should be
>>reworked. But there there is no need to outright avoid the use of
>>'goto'. if() is simply a conditional test with a goto A or goto B logic.
>But if the if() is already there, there is no need to have an additional
>goto in the statement, My version may even be faster than linus'
>version because it may save an extra assembler line of code (the beq or
>whatever branch statement generated by the if would do the branch during
>the if rather than after the if was evaluated and got to the first
>statement which was the goto). Of course, compiler optimizatoins
>probably make that particular point pointless to discuss.
>>There is a reason for the implementation of goto. When it all boils
>>down to it, in assembler it's all a matter of JMP with or without a
>But in this case, the condition was already there.. My point is that if
>you don't need a goto, you shouldn't use it. Whenever there's an
>obvious way not to use it, don't.
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


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 13:32    [W:0.091 / U:1.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site