Re: Backpatch?

hebert@prism.uvsq.fr (Renaud HEBERT)
Thu, 20 Jul 1995 09:13:14 GMT

          From comp.compilers
Related articles
Backpatch? diaman@ee.upatras.gr (Nikos Diamantopoulos) (1995-06-25)
Re: Backpatch? boggs@osage.csc.ti.com (1995-06-30)
Re: Backpatch? gclind01@ulkyvx.louisville.edu (1995-07-01)
Re: Backpatch? IanC@gibside.demon.co.uk (Ian Cull) (1995-07-05)
Re: Backpatch? taweil@ucs.usc.edu (1995-07-13)
Re: Backpatch? jcea@ait.uvigo.es (1995-07-19)
Re: Backpatch? hebert@prism.uvsq.fr (1995-07-20)
Re: Backpatch? albaugh@agames.com (1995-07-20)
| List of all articles for this month |
Newsgroups: comp.compilers
From: hebert@prism.uvsq.fr (Renaud HEBERT)
Keywords: code
Organization: Lab. PRiSM, Universite de Versailles-Saint Quentin, France
References: 95-07-033 95-07-120
Date: Thu, 20 Jul 1995 09:13:14 GMT

jcea@ait.uvigo.es (Jesus Cea Avion) writes:
|>[if you're chaining references to undefined variables, how do you handle
|> things like this?]
|> move.l #tableend-table,d0


Well I made a meta-assembler in which I solved this problem by using expression
instead of variables in the backpatching.
In summary each variable was associted with a pointer toward
a) the location in the code where it was used in a case like sub.l #table,d0
b) the location in the expression it was used in a case like
move.l #tableend-table,d0 the expression itself tableend-table was associted
with a pointer toward the location in the code.


When the value of the variable was know it was replaced in the code or in the
expression. And when there wasn't any unknown variable left in an expression
this expression was computed and the result was replaced within the code.


Of course a variable could be used at many points, so you have to keep a linked
list of all the locations it could be used.


Hope this helps.


--
Renaud HEBERT E-mail: Renaud.Hebert@prism.uvsq.fr
Serveur Mosaic: http://www.prism.uvsq.fr
--

Post a followup to this message

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