Return-Path: Message-ID: <50282bd30801301156w69822b14m744de8cd2374b37a@mail.gmail.com> Date: Wed, 30 Jan 2008 16:56:49 -0300 From: "Cidorvan Leite" To: "BlueZ development" In-Reply-To: MIME-Version: 1.0 References: <50282bd30801290946l359dc7a6j29bb3b891ab35f9a@mail.gmail.com> <1201715271.6218.106.camel@violet> Subject: Re: [Bluez-devel] ARM optimization Reply-To: BlueZ development List-Id: BlueZ development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Sender: bluez-devel-bounces@lists.sourceforge.net Errors-To: bluez-devel-bounces@lists.sourceforge.net Hi! On Jan 30, 2008 4:26 PM, Brad Midgley wrote: > Marcel > > The other macros are not being used and I had intended to remove them. > We use only MUL/MULA. > > > My idea would be to keep the semantic of MULA and only make it a two > > stage thing. In case of no assembler we still use MULA as it is right > > now, but in case of assembler it calls MULA_ARM which will do the > > calculations and then the assignment. Will this work? Is the compiler > > smart enough to optimize the code properly. > > I don't know how to do this but maybe Cidorvan can see it. > Like you can see in my first e-mail (gcc-no-arm-optimization.txt), gcc wasn't smart enough to optimize assignments. The reason to do a macro with assembly code is to force the gcc to use the right instruction (smlal) and keep the output code clean. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bluez-devel mailing list Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel