This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] Add language-dependent post-parser
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