|Backpatch? email@example.com (Nikos Diamantopoulos) (1995-06-25)|
|Re: Backpatch? firstname.lastname@example.org (1995-06-30)|
|Re: Backpatch? email@example.com (1995-07-01)|
|Re: Backpatch? IanC@gibside.demon.co.uk (Ian Cull) (1995-07-05)|
|Re: Backpatch? firstname.lastname@example.org (1995-07-13)|
|Re: Backpatch? email@example.com (1995-07-19)|
|Re: Backpatch? firstname.lastname@example.org (1995-07-20)|
|Re: Backpatch? email@example.com (1995-07-20)|
|From:||firstname.lastname@example.org (Renaud HEBERT)|
|Organization:||Lab. PRiSM, Universite de Versailles-Saint Quentin, France|
|Date:||Thu, 20 Jul 1995 09:13:14 GMT|
email@example.com (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
Return to the
Search the comp.compilers archives again.