From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9496 invoked by alias); 31 Mar 2004 16:58:11 -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 9482 invoked from network); 31 Mar 2004 16:58:08 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 31 Mar 2004 16:58:08 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1B8j2Y-0008TH-Cw; Wed, 31 Mar 2004 11:58:10 -0500 Date: Wed, 31 Mar 2004 16:58:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Paul Hilfinger , gdb-patches@sources.redhat.com Subject: Re: [RFA] Add language-dependent post-parser Message-ID: <20040331165810.GA32347@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Paul Hilfinger , gdb-patches@sources.redhat.com References: <20040330092413.2E716F281D@nile.gnat.com> <20040330142656.GA18340@nevyn.them.org> <20040331080245.C139FF2B8B@nile.gnat.com> <20040331153004.GA29623@nevyn.them.org> <20040331153650.GA30084@nevyn.them.org> <406AF6AE.5040106@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <406AF6AE.5040106@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03/txt/msg00763.txt.bz2 On Wed, Mar 31, 2004 at 11:49:50AM -0500, Andrew Cagney wrote: > > >>>>>> > I don't see why you can't do it, for instance, here: > >>>>>> > simple_exp : simple_exp '(' arglist ')' > >>>>>> > { > >>>>>> > write_exp_elt_opcode (OP_FUNCALL); > >>>>>> > write_exp_elt_longcst ($3); > >>>>>> > /* check arguments */ > >>>>>> > write_exp_elt_opcode (OP_FUNCALL); > >>>>>> > } > >>>>>> > ; > >>> > >>>>> > >>> > >>>>>> > You'd have to wiggle the expression machinery to give you back the > >>>>>> > expression node for the function name, probably by making the > >>>>>> > write_exp_* functions return a pointer. But that's less intrusive > >>>>>and > >>>>>> > more efficient than adding a second pass. > >>> > >>>>> > >>>>> Yes, that's exactly how I'd LIKE to do it. And I would, but for one > >>>>> miserable little fact: the expression at this point is in POSTFIX > >>>>> form. So, for example, I can't use evaluate_type or the evaluate_exp > >>>>> member of exp_descriptor, both of which work on PREFIX form. > >> > >>> > >>>How much work would it be to duplicate and prefixify them, then? > >>>prefixify_subexp has the right interface already; if you write out the > >>>OP_FUNCALL, you could then call a function which returns a new struct > >>>expression in prefix form containing just the call and its arguments. > >>>It would just need to allocate enough memory (could be generous about > >>>it and just use the size of the original expression), call > >>>prefixify_subexp, and fiddle out->nelts. > >>> > >>>OK, it's not so _efficient_, but... it could be made efficient if > >>>someone overhauls the representation at some point. > > > > > >But I guess the point is, this is no more elegant than a second pass, > >and whatever you implement I should probably use for C++ anyway so it > >won't be an Ada-specific hook. Does anyone else have an opinion? > > Ok, two thoughts: > > - how come it's in this compressed postfix form? > This could hardly be a memory usage problem? Hardly - since expressions are so short-lived. I think it's more likely the emphasis was on postfix than on compressed. I wasn't around when any of this was being designed, of course :) But there are two plausible ways to structure this sort of yacc parser - either postfix or tree. Apparently someone prefered postfix. Which is then awkward to work with so it becomes prefix later. If we're going to really clean this up, I think that using a tree instead would be the way to go. That's a lot of work though. > - could multi-pass be better / cleaner long term? > Is there a language (that we care about) with overload semantics so > screwed up that both the containing expression and the parameters are > needed when resolving the name? I don't think there is. > One way to get an answer is to ask: how to the corresponding compilers > (Ada, Java, ObjC, C++) all implement this? The only ones I'm familiar with (GCC, EDG, etc.) all do it using a tree structure. A linearized representation is just too restrictive. And multi-pass is out of the question if you want good performance; while for GDB the performance of the expression parser is pretty marginal, and the expressions we parse are pretty small, for a compiler this is a critical bottleneck. Every additional pass over the parse tree has a high cost. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer