From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760272AbXGCTQU (ORCPT ); Tue, 3 Jul 2007 15:16:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755802AbXGCTQM (ORCPT ); Tue, 3 Jul 2007 15:16:12 -0400 Received: from bc.sympatico.ca ([209.226.175.184]:36846 "EHLO tomts22-srv.bellnexxia.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755664AbXGCTQL (ORCPT ); Tue, 3 Jul 2007 15:16:11 -0400 Date: Tue, 3 Jul 2007 15:16:05 -0400 From: Mathieu Desnoyers To: "H. Peter Anvin" Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org Subject: Re: [patch 06/10] Immediate Value - i386 Optimization Message-ID: <20070703191605.GB4047@Krystal> References: <20070703164046.645090494@polymtl.ca> <20070703164515.071300768@polymtl.ca> <468A9956.9050903@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <468A9956.9050903@zytor.com> X-Editor: vi X-Info: http://krystal.dyndns.org:8080 X-Operating-System: Linux/2.6.21.3-grsec (i686) X-Uptime: 15:00:52 up 2 days, 13:43, 3 users, load average: 0.48, 0.19, 0.17 User-Agent: Mutt/1.5.13 (2006-08-11) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org * H. Peter Anvin (hpa@zytor.com) wrote: > What is not clear to me is the exact code that is generated by these > macros. Nor can I find it anywhere in the documentation. > > Could you please describe this in some detail? In particular, it seems > that the uses of these are largely as branch targets, where the extra > indirection over modifying the jump target directly seems wasted. > Hi Peter, I understand your concern. If you find a way to let the code be compiled by gcc, put at the end of the functions (never being a branch target) and then, dynamically, get the address of the branch instruction and patch it, all that in cooperation with gcc, I would be glad to hear from it. What I found is that gcc lets us do anything that touches variables/registers in an inline assembly, but does not permit to place branch instructions ourselves; it does not expect the execution flow to be changed in inline asms. Here is an objdump of the interesting bits on an immediate value placed in scheddule (inline schedule_debug). 00000000 : 0: 55 push %ebp 1: 89 e5 mov %esp,%ebp 3: 57 push %edi 4: 56 push %esi 5: 53 push %ebx 6: 83 ec 40 sub $0x40,%esp 9: b8 01 00 00 00 mov $0x1,%eax e: e8 fc ff ff ff call f 13: e8 fc ff ff ff call 14 18: 89 45 dc mov %eax,0xffffffdc(%ebp) 1b: b8 00 00 00 00 mov $0x0,%eax 20: 8b 4d dc mov 0xffffffdc(%ebp),%ecx 23: 8b 14 8d 00 00 00 00 mov 0x0(,%ecx,4),%edx 2a: 01 d0 add %edx,%eax 2c: 89 45 d0 mov %eax,0xffffffd0(%ebp) 2f: b8 00 00 00 00 mov $0x0,%eax 34: c7 44 02 04 01 00 00 movl $0x1,0x4(%edx,%eax,1) 3b: 00 3c: 8b 5d d0 mov 0xffffffd0(%ebp),%ebx 3f: 8b 9b f0 03 00 00 mov 0x3f0(%ebx),%ebx 45: 89 5d c8 mov %ebx,0xffffffc8(%ebp) 48: 81 c3 94 01 00 00 add $0x194,%ebx 4e: 89 5d cc mov %ebx,0xffffffcc(%ebp) 51: 8b 45 c8 mov 0xffffffc8(%ebp),%eax 54: 8b 40 14 mov 0x14(%eax),%eax 57: 85 c0 test %eax,%eax 59: 0f 89 30 03 00 00 jns 38f 5f: 89 e0 mov %esp,%eax 61: 25 00 e0 ff ff and $0xffffe000,%eax 66: 8b 40 14 mov 0x14(%eax),%eax 69: 25 ff ff ff ef and $0xefffffff,%eax 6e: 83 e8 01 sub $0x1,%eax 71: 0f 85 fb 02 00 00 jne 372 77: b8 00 00 00 00 mov $0x0,%eax 7c: 85 c0 test %eax,%eax 7e: 0f 85 16 03 00 00 jne 39a here, we just loaded 0 in eax (movl used to make sure we populate the whole register so we do not stall the pipeline)a When we activate the site, line 77 becomes: b8 01 00 00 00 mov $0x1,%eax 84: 8b 45 d0 mov 0xffffffd0(%ebp),%eax 87: e8 fc ff ff ff call 88 8c: 8b 4d c8 mov 0xffffffc8(%ebp),%ecx 8f: 8b 41 04 mov 0x4(%ecx),%eax 92: f0 0f ba 70 08 02 lock btrl $0x2,0x8(%eax) ... 39a: 8b 55 04 mov 0x4(%ebp),%edx 39d: b9 01 00 00 00 mov $0x1,%ecx 3a2: b8 02 00 00 00 mov $0x2,%eax 3a7: e8 fc ff ff ff call 3a8 3ac: e9 d3 fc ff ff jmp 84 -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68