Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S267523AbTALU1L>; Sun, 12 Jan 2003 15:27:11 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S267525AbTALU0E>; Sun, 12 Jan 2003 15:26:04 -0500
Received: from 60.54.252.64.snet.net ([64.252.54.60]:6518 "EHLO
	mail.blue-labs.org") by vger.kernel.org with ESMTP
	id <S267524AbTALUZh>; Sun, 12 Jan 2003 15:25:37 -0500
Message-ID: <3E21D14C.4040401@blue-labs.org>
Date: Sun, 12 Jan 2003 15:34:20 -0500
From: David Ford <david+cert@blue-labs.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030110
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: robw@optonline.net
CC: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: any chance of 2.6.0-test*?
References: <Pine.LNX.4.44.0301121100380.14031-100000@home.transmeta.com> <1042400094.1208.26.camel@RobsPC.RobertWilkens.com> <20030112194100.A15036@infradead.org> <1042400474.3162.32.camel@RobsPC.RobertWilkens.com> <3E21C8D5.5010301@blue-labs.org> <1042402051.3162.59.camel@RobsPC.RobertWilkens.com>
In-Reply-To: <1042402051.3162.59.camel@RobsPC.RobertWilkens.com>
X-Enigmail-Version: 0.71.3.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2281
Lines: 64

-----BEGIN PGP SIGNED MESSAGE-----
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.

David

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 
>>condition.
>>    
>>
>
>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.
>
>-Rob
>  
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+IdFM74cGT/9uvgsRAuMkAJ4nKED1gEVvNKJiYqXg6J73aQgTRQCfWrrJ
zYoHzuMjZ+ikKHCQ1O9E2C4=
=PBlz
-----END PGP SIGNATURE-----

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/