Re: linker magic: dynamic meta handlers...

"Hans-Peter Diettrich" <DrDiettrich1@aol.com> wrote in message
> cr88192 schrieb:
>
>> I am wondering here if anyone has comments, or thinks I am approaching
>> all
>> this in totally the wrong way, ...
>
> First guess: you try to reinvent JIT compilation?


I am doing JIT, just as it so happens my approach to JIT has an
assembler and a linker thrown in the mix, and my code follows most of
the usual rules of producing ASM and doing linking...


what this means though, is that one can't just hard-code the addresses
of things into the ASM code (well, it is possible, just not good
practice IMO, especially in light of things like caching object code
and similar), and so, more commonly, one accesses variables
symbolically, and lets the linker link things up.


of course, there are edge-cases, which is what all this tries to address...




typically dynamic code generation consists of generating chunks of ASM
and passing them off to the assembler, which assembles and links them
into the running image.


a slight variation of the linking process is used for GC'able
functions/thunks (they follow slightly different rules WRT symbol
linkages and in general can't export anything into the global
toplevel, instead using local toplevels, ...), but otherwise the
process is about the same (assembler produces in-memory objects, and
the linker links them...).




the compiler typically also produces ASM code, which is then fed into
the assembler. in general though, thus far I am managing to get far
more use out of the assembler than the compiler though (and a lot more
use out of crafting very special-purpose pieces of assembler than out
of general-purpose code generation). but oh well...




(I am aware though that many frameworks using JIT typically just use a
bunch of special-purpose function calls to generate raw machine code,
but IMO this is both awkward and not very general purpose, and I much
rather produce textual ASM, in my case using an NASM/Intel-style
syntax...).


(granted though that to port my project to something other than x86 or
x86-64 would require some level of re-engineering, such as largely
reworking the assembler, linker, and nearly everything else, but I try
to keep most of the parts fairly general if possible...).

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