Re: Writing Assembler!

Charles Fiterman <>
22 May 1997 22:40:07 -0400

          From comp.compilers

Related articles
[2 earlier articles]
Re: Writing Assembler! (Clark L. Coleman) (1997-05-16)
Re: Writing Assembler! (1997-05-17)
Re: Writing Assembler! (Ben Bullock) (1997-05-17)
Re: Writing Assembler! (1997-05-17)
Re: Writing Assembler! (Mr J R Hall) (1997-05-22)
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)
[8 later articles]
| List of all articles for this month |

From: Charles Fiterman <>
Newsgroups: comp.compilers
Date: 22 May 1997 22:40:07 -0400
Organization: Geodesic Systems
References: 97-05-156
Keywords: assembler

Khoo Kiak Wei <> wrote:
>I am planning to write a generic assembler, as a work of learning
>flex and bison. However, after reading a book on Lex and Yacc, I am
>still confused on how should I start!?
>If any of you know of any sample code on assembler or good books talking
>on the assembler construction, I would like to hear from you please!

I've written a few. A good place to start is the GNU assembler gas.
But that comes with the dread copyleft and since I like to eat I can't
use it as a starting point.

I'm going to suggest that you start with a file which has all the
information on the instruction set including documentation on the
instructions and macros. Then write a Perl program that outputs a pre
hashed symbol table and part of your documention in troff or what ever
you use. I considered perfect hashing but it doesn't work well on
tables that size. Also you will add macros to your table.

And you do need a macro assembler, you can't use something like cpp or
m4. This is because your macros will need access to addresses for many
techniques. Be sure to use object oriented input so you can redirect
input to things of your own construction.

I dislike lex and can do as well on my own and have faster code but
like Bison etc for parsing. Be sure to stay object oriented and keep
the connection to your output format loose.

The key to speed is what I call the see file, eat file technique.
Don't read files a line at a time, get their length and inhale. Being
able to output pre linked ontput to ram is good for compile as needed

Post a followup to this message

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