|a newbie's dumb question... email@example.com (2001-07-18)|
|Re: a newbie's dumb question... firstname.lastname@example.org (Vinay Kakade) (2001-07-23)|
|Re: a newbie's dumb question... email@example.com (Joachim Durchholz) (2001-07-23)|
|Re: a newbie's dumb question... firstname.lastname@example.org (2001-07-23)|
|Re: a newbie's dumb question... email@example.com (ThaFacka) (2001-07-23)|
|Re: a newbie's dumb question... firstname.lastname@example.org (2001-07-27)|
|Re: a newbie's dumb question... email@example.com (James Grosbach) (2001-07-30)|
|From:||"Joachim Durchholz" <firstname.lastname@example.org>|
|Date:||23 Jul 2001 02:19:24 -0400|
|Posted-Date:||23 Jul 2001 02:19:24 EDT|
Sunny <email@example.com> 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. 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.
If your assembler is the usual tabular layout, parsing it is so trivial
that you don't need a parser generator like yacc.
> 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??
It's a trade-off. That way, he has all information readily available
(good if you want to report errors like "JMP target appears nowhere"
or similar nonlocal stuff). Uses up more memory, could become a slight
problem if the assembler code is huge (e.g. assembly generated by a
compiler), or if the compilation happens on a very small machine.
(Memory was more important just a few years ago, but it's usually not
a serious problem anymore.)
> 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??
Write a parser that identifies the various columns of the assembly; the
error cases will fall out naturally.
Finding the error cases is easy; printing understandable messages might
be more of a challenge.
> 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? So am I just need to find the types of grammars (eg
> opcode label, label opcode number)??
Parsers are much more important if you have languages with nested
structures. For assembly, there isn't much to them. (Unless you have a
sophisticated macro processor in your assembler. Macro language can be
complicated enough to warrant using a parser generator.)
Return to the
Search the comp.compilers archives again.