Re: Writing Assembler!

rick@tip.nl (rickn)
15 Jun 1997 22:44:53 -0400

          From comp.compilers

Related articles
[14 earlier articles]
Re: Writing Assembler! landon@netcom.com (1997-06-11)
Re: Writing Assembler! cliffc@risc.sps.mot.com (Cliff Click) (1997-06-11)
Re: Writing Assembler! albaugh@agames.com (1997-06-13)
Re: Writing Assembler! genew@vip.net (1997-06-13)
Re: Writing Assembler! jhallen@world.std.com (1997-06-13)
Re: Writing Assembler! cyber_surfer@wildcard.demon.co.uk (Cyber Surfer) (1997-06-15)
Re: Writing Assembler! rick@tip.nl (1997-06-15)
Re: Writing Assembler! csusb@csv.warwick.ac.uk (1997-06-15)
Re: Writing Assembler! cliffc@risc.sps.mot.com (Cliff Click) (1997-06-19)
| List of all articles for this month |

From: rick@tip.nl (rickn)
Newsgroups: comp.compilers
Date: 15 Jun 1997 22:44:53 -0400
Organization: NL-NIC
References: 97-05-156 97-05-281
Keywords: assembler

mark@omnifest.uwm.edu (Mark Hopkins) wrote:


> What should go into the design of an assembler? I'll give you a
>head start by listing what I think the ideal design should look like.


>(A) Resolution of Operations


I hope you forgive me that I skip your nice explanation, for
shortness..When I understand you correctly then the levels of the
assembler you are pointing at here have something to do with the
"compiler" capacities of the assembler right ? At the first level the
assembler only recognizes the valid opcodes( while generating
appropriate errormessages I hope for invalid ones), but later on the
assembler is getting smart..Trivial example would be the use of JCC
opposite and JMP. When I follow your approach the next thing I want to
know is what exactly is the list of meaningful operands for mnemonics(
and which ones are not directly supported). This is NOT trivial. Some
operands are not allowed for good reason( at least that is what I
think now). Take for instance pop CS or mov CS,reg. So how about
making such a list ?


>(B) Resolution of Addresses


In the development of my 80x86 assembler I am just getting to this
level so I do not have much to say/ask here. I doubt very
much that I even understand exactly what you mean, but lets
see:
You are speaking of two passes, which seems to me very logical.
In fact I would have enough difficultie holding the passes at two.


Take labels( easiest case I think)
You have to resolve the code partly before you can get to the
adresses. After the first pass you know the codesize apart from
your relative loops/calls/jmps/JCC( when we forgot about variables etc
for a moment). But then it might still be that the jmp/JCC is
wordsized or bytesized. Say that my first jmp can be resolved to
bytesize then I have to substract 1 from the adresses after that.
That would even invalidate nested backward jmps( which I thought to
resolve at first pass). But allright, that would be not to difficult
to update the symboltable after resolving a label.
But then again you are speaking about 1 pass ??


And also you seems to speak about object files which list in some way
the not resolved adresses, and leave the adress resolution up to the
linker. You really lost me there( but I have still to do a lot of .obj
format reading ;)), especially since you speak about partially solving
the code in first pass( which I thought was normal since otherwise you
won't get an adress...)


>(C) User-Defined Operations and Directives


This is not for me at this moment( estimated time of arrival: 1 month)
BTW what is exactly orthogonal ?


Rick
[Techniques for handling variable sized jumps are well known. Doing a
perfect job is NP complete, but you can do a pretty decent job in one
pass by buffering enough output to catch most jumps that can be made
short. -John]




--


Post a followup to this message

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