From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15389 invoked by alias); 8 Jul 2014 11:32:02 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 15330 invoked by uid 89); 8 Jul 2014 11:31:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e06smtp14.uk.ibm.com Received: from e06smtp14.uk.ibm.com (HELO e06smtp14.uk.ibm.com) (195.75.94.110) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 08 Jul 2014 11:31:56 +0000 Received: from /spool/local by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 8 Jul 2014 12:31:53 +0100 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp14.uk.ibm.com (192.168.101.144) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 8 Jul 2014 12:31:49 +0100 Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id A086E1B08069 for ; Tue, 8 Jul 2014 12:32:26 +0100 (BST) Received: from d06av08.portsmouth.uk.ibm.com (d06av08.portsmouth.uk.ibm.com [9.149.37.249]) by b06cxnps4074.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s68BVnxX5898352 for ; Tue, 8 Jul 2014 11:31:49 GMT Received: from d06av08.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s68BVm7i011724 for ; Tue, 8 Jul 2014 05:31:49 -0600 Received: from br87z6lw.de.ibm.com (dyn-9-152-212-196.boeblingen.de.ibm.com [9.152.212.196]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s68BVl5r011675; Tue, 8 Jul 2014 05:31:48 -0600 From: Andreas Arnez To: Omair Javaid Cc: "gdb-patches\@sourceware.org" , Yao Qi , Mark Kettenis Subject: Re: [PATCH v2 02/13] regcache: Add functions suitable for regset_supply/collect. References: <1403714949-28133-1-git-send-email-arnez@linux.vnet.ibm.com> <1403714949-28133-3-git-send-email-arnez@linux.vnet.ibm.com> Date: Tue, 08 Jul 2014 11:32:00 -0000 In-Reply-To: (Omair Javaid's message of "Mon, 7 Jul 2014 14:32:21 +0500") Message-ID: <87lhs4f5ng.fsf@br87z6lw.de.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14070811-1948-0000-0000-000000748001 X-IsSubscribed: yes X-SW-Source: 2014-07/txt/msg00147.txt.bz2 On Mon, Jul 07 2014, Omair Javaid wrote: > Is there a way around avoiding the loop in supply/collect where regnum > != -1? It should be more efficient in cases where we are looking for a > register with regnum > 0. Good question. The most straightforward way would be a register map format where regnum is used as an index into an array of offsets, like this: int s390_regmap_gregset[S390_NUM_REGS] = { /* Program Status Word. */ 0x00, 0x04, /* General Purpose Registers. */ 0x08, 0x0c, 0x10, 0x14, 0x18, 0x1c, 0x20, 0x24, 0x28, 0x2c, 0x30, 0x34, 0x38, 0x3c, 0x40, 0x44, /* Access Registers. */ 0x48, 0x4c, 0x50, 0x54, 0x58, 0x5c, 0x60, 0x64, 0x68, 0x6c, 0x70, 0x74, 0x78, 0x7c, 0x80, 0x84, /* Floating Point Control Word. */ -1, /* Floating Point Registers. */ -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /* GPR Uppper Halves. */ -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /* GNU/Linux-specific optional "registers". */ 0x88, -1, -1, }; This is a real example. For the full example refer to: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/s390-tdep.c;h=72d55450225e89da4394079efac1fa33b36cb68c;hb=d91fab15e7eb04f6c9b7fee5859d8815b7aa84ee#l412 As you see, this is where the s390 implementation came from. Then I realized that regnum > 0 is a very rare case, and that the common case was suboptimal with this format, because the supply/collect functions had to iterate over *all* registers, not just those of a specific regset. Patch #3 in this series expresses the regmap from above like this: static const struct regcache_map_entry s390_gregmap[] = { { 1, S390_PSWM_REGNUM }, { 1, S390_PSWA_REGNUM }, { 16, S390_R0_REGNUM }, { 16, S390_A0_REGNUM }, { 1, S390_ORIG_R2_REGNUM }, { 0 } }; In addition to being more efficient in the common case, I also consider this version much easier to read and maintain. We could certainly spend more effort on supplying and collecting a single register more efficiently. For instance, we could offer additional routines for that special case, perhaps in conjunction with a preparation function that converts a regmap to an indexed-by-regnum array. However, I wouldn't focus on that too much before actually making use of it. Note that currently these functions are *always* called with regnum == -1. In fact, it may be more adequate to completely get rid of the parameter regnum in the regset supply/collect functions. Any reason why we shouldn't?