Re: Best tools for writing an assembler?

I keep expecting to see Chris Clark jump in here. 8-)




On Thu, 27 Feb 2014 18:11:28 -0500, noitalmost <noitalmost@cox.net>
wrote:


>... 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.


That's true of any tool.


However, parsers are notoriously difficult to get correct: it's not
enough that your parser recognizes the language, it also has to reject
everything else. That can be quite hard to verify.


Keep in mind that there are both LR and LL parser tools. LR tools
produce table driven state machines, but LL tools produce recursive
decent code that can be read and (fairly) easily understood.


I would steer the OP to something like ANTLR instead of Bison/Flex.
ANTLR even has a (separate) GUI that displays syntax diagrams for the
grammar and you can test your grammar within the GUI without needing
to write a program.
[Only caveat is the ANTLR tool requires Java to run. It does *not*
require that _your_ program also be written in Java - it can generate
parsers and lexers in several languages.]




>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!"


Using a parser tool initially is more about correctness than about
saving time. Time savings come with ongoing maintenance, if any.




>Sibastien Fricker wrote:
>> 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.


Assembler still can be pretty complex. I've used assemblers that had
C like expression syntax.




>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.


And a C++ compiler isn't a giant black box?




>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.


This is a valid concern, but IMO it is exaggerated. In a day or so
you can learn enough about the tool to begin working in earnest. Most
projects will never need the more complicated options provided by the
tool and those can be learned as you go.


Bison in particular has a complicated set of options ... which, again,
is why I would start with a different tool. Learn Bison if and when
you need to.




>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.


LL tools don't have mysterious shift/reduce, reduce/reduce conflicts.
The learning curve for LL tools is much shallower.




>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.


No use of any compiler/generator is "trivial" - it all requires some
level of understanding, both of the tool and it's expected input.


YMMV,
George

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