From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Landley Subject: Re: [tip:x86/asm] x86, bitops: Change bitops to be native operand size Date: Sat, 30 Nov 2013 17:16:22 -0600 Message-ID: <1385853382.1974.297@driftwood> References: <1384117768.3081.10.camel@joe-AO722> <5ac67859-a0b2-47f5-bdc2-c2a52b8d6885@email.android.com> <1384123457.3081.33.camel@joe-AO722> <52803BA2.2080908@zytor.com> <1384136570.4771.5.camel@joe-AO722> <5281698F.9080808@linux.intel.com> <1384224883.4771.28.camel@joe-AO722> <1384229308.4771.35.camel@joe-AO722> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Transfer-Encoding: 8BIT Return-path: In-Reply-To: (from geert@linux-m68k.org on Tue Nov 12 02:52:57 2013) Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org To: Geert Uytterhoeven Cc: Joe Perches , "H. Peter Anvin" , "H. Peter Anvin" , linux-arch , Ingo Molnar , Linux Kernel Mailing List , Thomas Gleixner , james.t.kukunas@intel.com, David Miller List-Id: linux-arch.vger.kernel.org On 11/12/2013 02:52:57 AM, Geert Uytterhoeven wrote: > On Tue, Nov 12, 2013 at 5:08 AM, Joe Perches wrote: > > On Tue, 2013-11-12 at 12:15 +0900, Linus Torvalds wrote: > >> Talking about "ideal implementation" is also singularly stupid. > > > > I just want the various arch implementations to match > > the docs. I know that's stupid. > > > > Maybe if you really don't want to discuss things, you > > should fix the documentation. > > E.g. by adding a paragraph that the actual allowed range of indices > may be > a subset of "unsigned long" on some architectures. > Or if we know that everyone supports at least 31 resp. 63 bits, that > it may > be limited to 31 resp. 63 unsigned bits, which is the positive range > subset of > "long". If this ever turns into an actual patch to this file, could you cc: me on it so I can marshal it upstream? (Not enough domain expertise for me to produce it myself...) Thanks, Rob From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa0-f43.google.com ([209.85.219.43]:45726 "EHLO mail-oa0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751403Ab3LAC20 convert rfc822-to-8bit (ORCPT ); Sat, 30 Nov 2013 21:28:26 -0500 Received: by mail-oa0-f43.google.com with SMTP id i7so11820471oag.30 for ; Sat, 30 Nov 2013 18:28:24 -0800 (PST) Date: Sat, 30 Nov 2013 17:16:22 -0600 From: Rob Landley Subject: Re: [tip:x86/asm] x86, bitops: Change bitops to be native operand size References: <1384117768.3081.10.camel@joe-AO722> <5ac67859-a0b2-47f5-bdc2-c2a52b8d6885@email.android.com> <1384123457.3081.33.camel@joe-AO722> <52803BA2.2080908@zytor.com> <1384136570.4771.5.camel@joe-AO722> <5281698F.9080808@linux.intel.com> <1384224883.4771.28.camel@joe-AO722> <1384229308.4771.35.camel@joe-AO722> In-Reply-To: (from geert@linux-m68k.org on Tue Nov 12 02:52:57 2013) Message-ID: <1385853382.1974.297@driftwood> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: 8BIT Sender: linux-arch-owner@vger.kernel.org List-ID: To: Geert Uytterhoeven Cc: Joe Perches , "H. Peter Anvin" , "H. Peter Anvin" , linux-arch , Ingo Molnar , Linux Kernel Mailing List , Thomas Gleixner , james.t.kukunas@intel.com, David Miller Message-ID: <20131130231622.qtLesnMQTJd10bdWeRYHrz5rgGLTa66ehi2Im6ijl00@z> On 11/12/2013 02:52:57 AM, Geert Uytterhoeven wrote: > On Tue, Nov 12, 2013 at 5:08 AM, Joe Perches wrote: > > On Tue, 2013-11-12 at 12:15 +0900, Linus Torvalds wrote: > >> Talking about "ideal implementation" is also singularly stupid. > > > > I just want the various arch implementations to match > > the docs. I know that's stupid. > > > > Maybe if you really don't want to discuss things, you > > should fix the documentation. > > E.g. by adding a paragraph that the actual allowed range of indices > may be > a subset of "unsigned long" on some architectures. > Or if we know that everyone supports at least 31 resp. 63 bits, that > it may > be limited to 31 resp. 63 unsigned bits, which is the positive range > subset of > "long". If this ever turns into an actual patch to this file, could you cc: me on it so I can marshal it upstream? (Not enough domain expertise for me to produce it myself...) Thanks, Rob