Re: Design Considerations of GIMPLE Front End

[Steven Bosscher <stevenb.gcc@gmail.com>]

On Tue, May 18, 2010 at 4:09 PM, Diego Novillo <dnovillo@google.com> wrote:
> On Tue, May 18, 2010 at 09:59, Michael Matz <matz@suse.de> wrote:
>
>> I don't see how that is much easier to parse compared to
>>  i_1 = k_1 + m_1
>>  j_1 = func (arg1, arg2)
>
> Well, it would make the parser almost trivial to implement.  But you
> have a point, the only structurally complex objects we need to parse
> are type declarations.  Everything else should have very uniform
> syntax.
>
>> The nice thing with tuples is that there's always only one operator, and
>> hence no ambiguity in precedence that needs to be resolved or explicitely
>> encoded via a list structure.
>
> That's true.
>
>> Or is the format also intended to be able to represent GENERIC, i.e.
>> deeply nested structures?
>
> No, just gimple.

IMHO, ideally we would have a syntax that is human readable and human
writable. S-expressions are not as easy to read for me as something
that resembles C.

Related subject: Is it possible to have a formal grammar of some kind
for, say, bison? It would be nice if we can generate different tools
from one grammar, e.g. a GIMPLE front end, a syntax checker, maybe
static analyzers, etc. If you make a reader that already constructs
the gimple data structures, it will be harder to construct multiple
tools on top of it that are independent of libbackend.

Ciao!
Steven