Re: Best tools for writing an assembler?

On Monday, February 24, 2014 01:32:37 AM Sibastien Fricker wrote:
> 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:
> 1) They are able to manage complex rules which would need many lines of
> code. For example, parsing an integer consists only of matching the
> regular expression pattern "[0-9]+". It is simple and more readable than
> writing directly its C++ code.


But you have to understand the grammar of those rules as expressed in
the scanner/parser tools. Until you've learned those tools, the C++
code will be more understandable to you, even if it's expressed more
verbosely. Readability is somewhat subjective and depends a lot on
what you're familiar with. You can do some pretty cool stuff in Latin
with only a word or two, but if you don't know Latin, the 15-word,
2-sentence English translation is much more readable. (I'm assuming,
of course, that you understand English, and aren't one of those crazy
monkeys with the typewriter that can generate Shakespearean sonnets.
:)


> 2) The generated code is optimized at a level different to what the
> compiler does. For example, if in your keyword you have "visual" and
> "virtual", the generated code will first match "vi" and then "rtual" or
> "sual". Of course writing such optimization by hand is practically not
> possible.


But this is the OP's first attempt at a relatively robust assembler.
Have you forgotten your first significant project? When the magical
feelings were "It works!" and "I know how it works!" rather than "I
saved a microsecond in assembly time!"


> 3) Flex/Bison are performing some error analysis which permits detect
> unused rules, unreachable states, ... All this checks are not existing
> for hand written parser. That's mean that your test suite need to handle
> such kind of non detected errors.


Very true, but we are talking about assembler syntax here.


> 4) Inserting a new keyword/extending a syntax of an existing parser is
> more safe. In fact, due to all checks make by the parser generator, if
> the code compiles without bison/flex warnings you can be sure that your
> new syntax extension does not collide with the existing one. In other
> words, you did not program a regression my extending your syntax.
>
> 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.


I don't think that's a valid comparison. To the new user, it's more
the reverse than anything. Until you've used a parser tool for quite a
while, it's like a giant black box. The scanner tool is a smaller
black box. But rather than a nice OOP class, it's more like the
structs of Win95 MFC. You have to understand a lot about the global
organization, plus a lot of implementation details, and you have 2
extra grammars to learn. In other words, you have to understand a lot
of stuff before you understand anything at all. I just don't think
it's worth it for assembler syntax. There's a good chance the OP will
just give up, frustrated and completely mystified. If we were talking
about parsing Perl syntax, that would be different. Or if the OP were
writing 10 assemblers, that would be different too.


I'm obviously not an expert in this field, and my experience in
compiler writing is rather slim. It consists of 3 not overly
sophisticated assemblers and 2 toy HLL compilers. My experience with
the frustration of "shift/reduce conflict" however, is of some value
here, I think.


And I don't mean to denegrate the value of any of the parser tools.
But they're only easy to use and integrate into your compiler once
you've learned how to use them, which isn't trivial.

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