Re: Jit Implementation

Philip Herron <herron.philip@googlemail.com> writes:
>From what i understand to Jit some kind of language, do your parsing
>into an IR maybe some optimizations to a code generator. So ok if we
>have successfully output target code for the processor would you use
>simply a system assembler or what i see some people have runtime
>assemblers to assemble this code, then where would this target code
>go?


JIT compiler normally compile to memory, and they generate binary code
directly without going through an assembler (at least they don't
usually produce assembly language source code as intermediate stage).


>Then how do you link it in a useful way?


You generate the code in memory, patch up all the places that already
reference the code; any later references can use the address directly,
no patching needed.


>And ultimately how would you execute this


By performing a (indirect) jump or call to this code. E.g., if the
code follows the C calling convention, you can call it from C by
casting its address to a function pointer, and calling that.


>What might work but i doubt seriously if it works like this, to
>generate a dynamic library .so and use dlsym to execute them from your
>runtime.


That's not the usual way, because it's significantly slower, and
involves quite a bit more complexity.


>[A JIT compiler has to do the moral equivalent of dlopen(), take a
>chunk of data and make it be code, with everything in memory rather
>than in files. On many architectures, you don't actually have to do
>anything since code and data are in the same address space so you can
>set a pointer to point to the code you just wrote and call it


Right, thanks to the magic of Von Neumann machines there is no
difference between code and data in memory. Dlopen() does quite a bit
more than nothing, so the part about the "moral equivalent of
dlopen()" strikes me as strange.


As mentioned in another posting, on many machines we have to ensure
cache consistency in software, because the caches are organized in the
Harvard way (separate code and data). Unfortunately, there is no
portable way to achieve cache consistency. Some architectures (e.g.,
PowerPC) don't even have an architectural way to do this (i.e., code
that works as intended on my PPC 7447a does not necessarily work on
some other PowerPC-based machine).


>but on others you do need some help from the system, e.g., on recent
>x86 where data pages are usually marked no-execute. -John]


You don't need any particular help. You just need to ask for memory
that is writable and executable, e.g., by allocating memory with


mmap(... PROT_EXEC|PROT_READ|PROT_WRITE ...)


Concerning "recent x86", other architectures with MMUs have had this
feature (a separate "executable" bit) for ages. Now (since the first
Opteron in 2003) they (IA-32, AMD64) have it, too. We asked
explicitly for executable memory before (because of the other
processors), that code continues to work on IA-32 and AMD64.


- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/

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