Re: a newbie's dumb question...

explosion78@hotmail.com (Sunny) wrote:
>I just strated to use lex and yacc to make a compiler for PICmicro
>assembler. I have gathered enough materials for lex and yacc over the
>internet.


I am nearly as newbie as you, as I started to use Flex/Bison
    Flex: ftp://ftp.digital.com/pub/GNU/non-gnu/flex/flex-2.5.4a.tar.gz
    ftp://ftp.lauton.com/pub/flex-2.5.4-unicode-patch.tar.gz
    Bison: ftp://alpha.gnu.org/gnu/cvs/
only last fall.


> But I still don't have a slight idea of making a compiler
>though. I've sort of done the lex part, creating token and stuff. But
>I can't do the yacc part yet.


The Bison manual has some examples. You could also look into a book about
compiler construction, for example Aho, Sethi & Ullman, "Compilers...",
Addison Wesley.


>A friend of mine has done it for 68HC11. His compiler reads the whole
>code first and stack it, then finds any errors. Is it a good way? Or
>is there another way??


Bison just reads at most one look-ahead token at time, and from that
makes a decisions whether to err or not. It can only handle LALR(1)
grammars though.


>And the errors.. I spent a lot of hours to seek any clues about
>error-checking. I found one compiler which had over 200 error
>messages... I can only think of branch range errors, labeling errors
>and nothing else. Can any of you give me some ideas??


I do not think generating errors is the problem, because when you detect
one, you must signal it.


The problem is error recovery, whether the parser should continue or stop.
If you find one error, there is normally no point in generating code for
that translation unit, but the compiler might still read ahead.


Then, in general, the more context dependencies the language has, the
useful is error recovery: In C++, one writes a defining name incorrectly,
and that screws up subsequent parsing, so one get one hundred errors as a
consequence of that.


>Finally, parsers. I sort of understand that it's hierarchical and it
>eventually comes down to the token that the lex makes. Is that all
>there is to it?


The parser generated by Bison only knows about the token numbers it gets
from the lexer. So one can hook up the lexer to return any number, for
example what it gets from a look-up table.


> So am I just need to find the types of grammars (eg
>opcode label, label opcode number)??


You need also to attach actions to the grammar rules. Then these grammar
rules should know how to build the output code. The generated parser only
reads the input once and does not backtrack, so it cannot be used as an
interpreter stepping around in the input text.


It is easiest to start with a simple example (say a calculator), and then
work it up.


    Hans Aberg * Email: Hans Aberg <haberg@member.ams.org>
                                    * Home Page: <http://www.matematik.su.se/~haberg/>
                                    * AMS member listing: <http://www.ams.org/cml/>

Return to the comp.compilers page.
Search the comp.compilers archives again.