Assembler: Forward ref. label

titsay@ms3.hinet.net ()
3 May 1999 01:56:09 -0400

          From comp.compilers

Related articles
Assembler: Forward ref. label titsay@ms3.hinet.net (1999-05-03)
Re: Assembler: Forward ref. label bill@megahits.com (Bill A.) (1999-05-03)
Re: Assembler: Forward ref. label rkrayhawk@aol.com (1999-05-07)
Re: Assembler: Forward ref. label roques@pond.sub.org (Christian von Roques) (1999-05-09)
Re: Assembler: Forward ref. label rkrayhawk@aol.com (1999-05-16)
Re: Assembler: Forward ref. label johnl@iecc.com (John R Levine) (1999-05-16)
| List of all articles for this month |

From: titsay@ms3.hinet.net ()
Newsgroups: comp.compilers
Date: 3 May 1999 01:56:09 -0400
Organization: DCI HiNet
Keywords: assembler, question, comment

Hi,
      I'm working on an assembler to generate binary code for a customized
cpu. It's a 2-pass assembler, 1st pass generate label address and 2nd pass
generate final code. I allow label to appear in expression, and this cause
a problem. If the expression conatins label computaion, and the result will not
be determined until 2nd pass, I select one-word instruction or two-word by the
expression result. Thats mean I cannot generate correct machine code and label
address in 1st pass.
      Any reference url or staring points are welcome.


      I give some lines to illustrate:


        start:
              mov ax, label1-label0 (if label1-label0<128, generate 1-word code
                                                            (if label1-label0>=128, generate 2-word code
              ...
              ...


        label0:
              mov ax,bx
              ...
              ...
        label1:
              call ...
              ...
        (end of code)
[This is similar to the variable length branch problem. To get correct
code, you need an intermediate pass between your 1st and second passes.
In the first pass, assume it's all two-word code and remember the places
you might have to adjust, then at the end of pass 1 go through and see
which ones can actually be short, rippling up all the symbols after each
code shrink, and repeat until you don't find any more. This isn't quite
optimal (it's apparently an NP complete problem) but it's close enough
and not hard to implement. There was an article in the CACM by Szymanski
about 20 years ago that explained this in detail. -John]


Post a followup to this message

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