Re: [RFA] Add language-dependent post-parser

[Daniel Jacobowitz <drow@false.org>]

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