Re: [RFA] ppc: include register numbers in gdbarch_tdep structure.

[Kevin Buettner <kevinb@redhat.com>]

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