Re: Best tools for writing an assembler?

Sibastien Fricker schrieb:


>> I think that by hand-writing your own scanner and parser, you'll get
>> to know your assembly syntax better. And unless you have something
>> really strange, simple recursive descent will work fine for the
>> parser.
>>
>
> Sorry, but even if Flex/Bison are difficult to setup, writing a parser
> by hand is not a good way to work.
> Tools like Flex/Bison give several advantages that you cannot cover by
> writing a parser by hand:
[...]


With an LL grammar it's not a big problem to write a recursive-descent
parser by hand. LL grammars also can be written in EBNF, which
typically results in both shorter and better readable/writeable
grammars (and parsers?). Also the (grammars for) recursive descent
parsers are easier to debug than table-driven parsers.


This IMO makes it safe enough to write LL parsers by hand. Grammar
checks then are performed by the compiler (for missing productions) and
linker (for unreachable productions).


> In other words, saying that writing parser by hand is better is the same
> as saying "why using object oriented programming? I can do the same in C
> with struct!" Yes, but the result is less readable, the compiler does
> does less verifications.


Which verifications do you have in mind? A compiler cannot check the
validity of an table driven lexer or parser, it only can find
syntactical errors in the generated code. Such errors either result from
a buggy generator, in which case you had to fix the generator yourself
or wait for bug fixes by its maintainer. Or they result from syntax
errors in the semantic code of the grammar, which have to be fixed anyhow.


> [Yacc or bison provides the pleasant assurance that the langauge your
> program parses is exactly the one in the grammar, and not some
> superset due to missing error checks. -John]


Grammars often (typically?) are supersets of a language, with semantic
checks added manually to the parser code. Using an parser generator does
not assure anything about sub-/supersets, then. This also makes it very
hard to switch the implementation language for such a grammar, because
the generated lexer and semantic code is encoded in a specific language.
I'm still waiting for an parser generator creating code for a different
or multiple implementation languages, from the same grammar.


That's not a big problem with languages *not* intended for the
generation of executable code (file format parsers...), but when you
ever want to develop an compiler *in* your new language, you have to
translate the entire parser generator and the grammar into that language
as well.




I've used (and sometimes modified) several parser generators myself, and
found only one goodie with them: an (interactive) grammar debugger like
in MetaS or TextTransformer. Such extensions IMO contribute much more to
the development of an language-conforming grammar than the use of an
mere lexer/parser code generator.


DoDi

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