Re: intermediary representation and bison?

[lfinsto1]

> After writing a simple interpreter for my simplified C language using
> bison, I'm currently planning to write a small and a really simple
> compiler for it using flex and bison as a front-end.

The difference between a compiler and an interpreter is not clearly
defined.  _Very_ roughly speaking, people usually talk about interpreters
when it's a program that accepts input interactively (like METAFONT) and
about compilers when it takes an input and produces an output without
allowing any kind of interaction while it's running (like GCC).  On the
other hand, TeX is sometimes called a compiler and it can be used
interactively.

> My problem right
> now is that I'm not pretty sure if I have to implement an intermediary
> representation for a given source script, or not. Actually, I'd like to
> do it but then I remember the mission/goal of bison, i.e does pattern
> matching and then executes an action if a rule matches, and by
> implementing an IR tree to walk through it later, it feels like I'm
> redoing bison's job...

That's what I think, whereby I believe that what Bison is meant to
implement is called a "finite-state machine".

> I could just place the code emitters right in the
> actions associated with the grammar rules and that's it. I still don't
> know what to do...
>
> Here is ideally what I want to construct given this little piece of code:
>
> int a, b, c;
>
> a = 5;
> b = 10;
> c = a + b;
>
> then bison would construct these trees for me:
>
>   ASSIGN  ---  ASSIGN  ---  ASSIGN
>   /    \       /    \       /    \
> ID   CONST   ID   CONST   ID    BINARY (+)
>                                   /   \
>                                  ID   ID
>
> And then, I would just traverse these trees (top to bottom, left to
> right) to emit bind the identifiers to registers and to emit the native
> opcodes. But I can also do these actions directly in the semantic rules
> without trees construction..
>
> Guys, any suggestions? I'm confused.

To the best of my knowledge, GCC uses Bison and it also creates an
intermediate representation of the code using a LISP-like syntax.   You
might want to look at what the GCC developers have done.

If this would be useful to you, I don't see any reason why you shouldn't
do it.  On the other hand, I think you could just use the actions in your
current grammar to write assembler code, or even plain machine-language
code, for a given processor type.  So it's really up to you.

What I think is that one shouldn't re-invent the wheel.  However, if
you're looking for suggestions, `comp.compilers' would be a good place to
ask.

Laurence