Re: Writing Assembler! (Mr J R Hall)
15 Jun 1997 22:47:00 -0400

          From comp.compilers

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

From: (Mr J R Hall)
Newsgroups: comp.compilers
Date: 15 Jun 1997 22:47:00 -0400
Organization: University of Warwick, UK
References: 97-05-156 97-05-289 97-06-022 97-06-037
Keywords: assembler, syntax

Cliff Click <> writes:
>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!]

100x I think is an overestimate; also a large proportion of the time
taken is IO time, which hasn't improved quite that much.

I've just run NASM on a (simplified so that it could be automatically
generated!) 1Mb source file, and it took 16.2 seconds of processor
time (running on a SPARC machine, probably about 40-50x faster than
the 286 mentioned above).

To be honest, it took about 10 seconds just to generate it! For your 3
seconds estimate, I take it you were assembling from memory to memory?

NASM's parser is hand written. It simply is easier for such a simple
grammar, we believed, to write it by hand. The parser isn't even table
driven; it's a recursive descent parser (we may rewrite it table
driven at some future stage for efficiency purposes).

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

None of the bug reports we've had for NASM have reported it accepting
incorrect syntax. Correct syntax that was not accepted was quite
common in the early stages though...

>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

NASM's grammar was certainly never really predefined. We just designed
it and implemented it in stages. First the format of lines; how labels
would be recognised, and how comments would be found. What
instructions looked like. What expressions for indirect addressing
look like, and so on.

>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

You probably gain over NASM there: we have a preprocessor that does
some string copying, etc. Also NASM is a 2-pass assembler, whereas
your would appear to have been single pass, which would vastly improve
performance... In the run mentioned above, NASM would probably have
taken only 10 seconds of processor time if it were single pass.

Post a followup to this message

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