Re: Writing Assembler!

Cliff Click <>
11 Jun 1997 00:06:00 -0400

          From comp.compilers

Related articles
[9 earlier articles]
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)
Re: Writing Assembler! (1997-06-15)
Re: Writing Assembler! (1997-06-15)
[1 later articles]
| List of all articles for this month |

From: Cliff Click <>
Newsgroups: comp.compilers
Date: 11 Jun 1997 00:06:00 -0400
Organization: RISC Software, Motorola
References: 97-05-156 97-05-245 97-05-289 97-06-022
Keywords: assembler, syntax

I've written several hand-generated assembler parsers in my life. All
are very fast (in at least one case it was 50x faster, thats fifty
times faster, not +50%). Computers are fast enough now (and I write
so very little assembly) that I no longer care. But at one time I
cared a great deal about assembler speed. [We routinely assembled 1Mb
of source code in 3 seconds on a 20Mhz 286. A modern PC probably has
100x the horsepower. Can your assembler do 1Mb in 0.03 seconds?
Probably not! Do you care? Probably not!]

>From the moderator:
> [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]

As for error checking, I have no idea if I let anything unwanted slip
by. In practice, I fixed the few common mistakes to print informative
messages and other assembler errors (i.e., failures to catch bad
syntax) were so infrequent as to be in the noise range.

>From (Mark Hopkins):
>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.

I'll guess I'll disagree here. I never used an "official" grammer,
just ones I rolled on my own. And they certainly were not the first
thing I designed in these assemblers. And I didn't need a _large_
number of ad-hoc routines for testing (a few for weird 1-of-a-kind
opcode syntax). The things are very regular and straightforward to

I never used extraneous holding buffers (because that implies copying
text, which is a no-no for speed). There are a few places that
collect info over the life of the assemble, such as a hash-table of
strings, the laid-out data and text sections, and a post-pass fixup


Cliff Click, Ph.D. Compiler Researcher & Designer
RISC Software, Motorola PowerPC Compilers (512) 891-7240

Post a followup to this message

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