From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25298 invoked by alias); 10 Dec 2001 21:22:16 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 23135 invoked from network); 10 Dec 2001 21:20:56 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 10 Dec 2001 21:20:56 -0000 Received: from cse.cygnus.com (cse.cygnus.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id NAA00938; Mon, 10 Dec 2001 13:20:53 -0800 (PST) Received: (from kev@localhost) by cse.cygnus.com (8.9.3/8.9.3) id OAA01406; Mon, 10 Dec 2001 14:20:45 -0700 Date: Mon, 10 Dec 2001 13:22:00 -0000 From: Kevin Buettner Message-Id: <1011210212045.ZM1405@ocotillo.lan> In-Reply-To: Elena Zannoni "Re: [RFA] ppc: include register numbers in gdbarch_tdep structure." (Dec 10, 3:47pm) References: <15379.50110.429092.453327@krustylu.cygnus.com> <3C150D60.631D281C@cygnus.com> <1011210202327.ZM32506@ocotillo.lan> <15381.8009.857527.631618@krustylu.cygnus.com> X-Mailer: Z-Mail (4.0.1 13Jan97 Caldera) To: Elena Zannoni , Kevin Buettner Subject: Re: [RFA] ppc: include register numbers in gdbarch_tdep structure. Cc: Michael Snyder , gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2001-12/txt/msg00285.txt.bz2 On Dec 10, 3:47pm, Elena Zannoni wrote: > Subject: Re: [RFA] ppc: include register numbers in gdbarch_tdep structure > > > #define PPC_MQ_REGNUM gdbarch_tdep (current_gdbarch)->ppc_mq_regnum > > > > As with most things we do there are pros and cons. On the pro side, I > > agree that it looks prettier and is easier to read. Also, having > > these defines makes it easier to convert the code back to using actual > > constants some day. These are both excellent reasons to do as Michael > > suggests. > > Why would you want to convert the code back? Andrew recently said the following: On paper, it should be possible to describe the entire raw regcache using constants. I'm finding that, in reality, until all the relevant framework is fleshed out (eg my regcache breakage, everything multi-arch) it isn't really possible. Sigh. This suggests to me that someday, though probably not very soon, it may indeed be possible to use actual constants. As you can probably tell, I really, really hate the overhead of a function call to provide the value of something that ought to be a constant. > Anyway, I find it also > easier to debug the code, if you don't have a macro. So do I. Perhaps someday GDB will have support for macros. > > The drawback to using a macro like this is that it hides what's really > > going on. (But note that it is this very same quality that enhances > > readability.) In this case, the macro looks like a constant, leading > > to the expectation that it is a constant and has the usual costs > > associated with constants. However, the runtime costs associated with > > using this expression are significantly greater than using a constant. > > > > But having a macro defined to be the same function call is not going > to speed up the evaluation. I wasn't claiming that it would. I was providing an argument against the use of a macro. My argument is that the macro hides (in the sense that you have to go look at the macro's definition) the fact that a function is being called. I wasn't claiming that the macro eliminated the function call. > > That said, those of us accustomed to working on GDB are used to this > > by now, aren't we? E.g, consider: > > > > for (regno = 0; regno < NUM_REGS; regno++) > > ... > > > > We all realize that a function is being called each time the test > > ``regno < NUM_REGS'' is performed, don't we? > > Sometimes, doing something because it was done in the past is not a > good metric. I think multiarch was developed leaving the macros > because it was a necessary thing to both minimize changes and keep > compatibility with non-multiarched targets. But here I would argue it > is a different situation. I agree. But I wasn't citing NUM_REGS as a historical precedent. Rather, I was noting that since we're all used to macros performing function calls for us, that my argument against the use of the macro wasn't a very strong one. > > If so, then I'm all in favor of Michael's suggestion. (Actually, I'm > > in favor of Michael's suggestion anyway. But, I do think we need to > > be more careful about how we write code that might potentially contain > > a hidden function call.) > > Sorry, I disagree. That's okay. I don't plan to do anything about this one way or another until there's been more discussion. Kevin