Re: Writing Assembler! (Mark Hopkins)
9 Jun 1997 23:49:30 -0400

          From comp.compilers

Related articles
[7 earlier articles]
Re: Writing Assembler! (JUKKA) (1997-05-22)
Re: Writing Assembler! (Charles Fiterman) (1997-05-22)
Re: Writing Assembler! (1997-05-25)
Re: Writing Assembler! (1997-05-25)
Re: Writing Assembler! (JUKKA) (1997-06-09)
Re: Writing Assembler! (1997-06-09)
Re: Writing Assembler! (1997-06-09)
Re: Writing Assembler! (1997-06-11)
Re: Writing Assembler! (Cliff Click) (1997-06-11)
Re: Writing Assembler! (1997-06-13)
Re: Writing Assembler! (1997-06-13)
Re: Writing Assembler! (1997-06-13)
Re: Writing Assembler! (Cyber Surfer) (1997-06-15)
[3 later articles]
| List of all articles for this month |

From: (Mark Hopkins)
Newsgroups: comp.compilers
Date: 9 Jun 1997 23:49:30 -0400
Organization: Omnifest
References: 97-05-156 97-05-245 97-05-289
Keywords: assembler, syntax, comment

>From (rickn):
>Why that ? Spaces does not seem to mean anything for asm... Even
>worse: since the number of possible instructions and fields are so
>limited why not use a lookup table with all of it ? Anyway I am using
>it in the assembler I am building in QBASIC and it seems to work out
>great. Scanning and parsing seems to me a waste in this case ...

>From the moderator:
> The reason I like to use something like yacc is that I can be confident
> that it will diagnose syntax errors. Hand-written parsers often let
> unanticipated bad syntax fall through the cracks.

Defining a grammar and setting up a parser, whether it be written by
hand or otherwise, is essential, because this provides the framework
on which to hang everything else. In a top-down program design
methodology, the grammar is the thing you'll be starting with at the
top level.

Without a grammar to base everything on, you'll find yourself writing
a large number of seemingly ad hoc routines to test various matching
conditions in input, your input handling will be dispersed all over
the place, as you find yourself having to use extraneous buffers to
hold snippets that you collect here and there, and the whole thing
will be disjointed and not very easily modifiable.

But I don't agree with the moderator, that parsing has to be
automated. A grammar, even that like C's, can be converted into a
non-recursive parsing algorithm quite easily, even by hand, with the
aid of reliable algebraic methods. I've incorporated C-like syntax in
an assembler, as well as in my port, C-BC, of UNIX BC, all using
hand-written parsers that work.

But even more, with hand-written parsers, you have the opportunity to
put in fixes "under the hood", since the whole state machine mechanism
is readily available to you. In contrast, the main intent of
automated parsers (like YACC) is to bury that state-machine mechanism
out of view, thereby complicating matters by removing the
opportunities for expediencies. The result is that parser-compatible
grammars have to be stated in a much more complicated form that is
otherwise necessary, the notable example being the highly redundant
ANSI-C grammar, because grammatical constraints cannot be efficiently
handled without the above-mentioned under-the-cover fixing, thus not
only compounding the problem, but also leading to the illusion of the
language being processed is more complicated than it actually is.
(Thus causing even more people to want to use automated parsers ... a
very pernicious feedback loop).
[It's certainly possible to write useful parsers by hand, but it's
surprisingly hard to ensure that your hand-written parser accepts only
the language you want to parse. -John]

Post a followup to this message

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