Re: Managing the JIT

"Armel" <armelasselin@hotmail.com> wrote in message
> "Philip Herron" <herron.philip@googlemail.com> a icrit dans le message de
>> [...]
>> something. I am having trouble finding more stuff on how this works
>> would be great if you could point me in the right direction?! :)
>
> I just felt on the asmjit project : http://code.google.com/p/asmjit/
> it seems that it does not contain megatons of code, you may find
> interesting to read it.


I am wondering though why there is such a tendency for JIT-based assemblers
to use a function-call driven interface...


I tried this before, and it is a generally awkward and unpleasant approach.
more so, it does not allow conveniently also storing ASM to files, loading
ASM from files, ...


OTOH, my assembler uses a textual interface (with a NASM / YASM style
syntax).


granted, my assembler currently does not address the issue of writing
"architecture neutral" ASM (actually, personally I don't really know how
this would be approached).




granted, one could debate that using a textual assembler (and, for that
matter, a separate linking step), could hurt performance during JIT, but
personally I haven't really found this issue to be a problem. at least when
compiling C, dealing with textual ASM seems to have very little cost.


I guess one could debate that: "using an API-driven approach to ASM does
constitute the lower-end of an compiler anyways, so why bother making the
ASM textual?...".


the main reason is flexibility:
the ability to dump ASM into files;
the ability to load ASM from files.


and genericness:
one can emit code which will also work in a generic assembler, such as NASM
or YASM, or load and use NASM style code in the JIT (or, for that matter,
GAS style syntax could be used, ...).




and as well:
the ability to write big chunks of ASM in the form of string constants,
which are passed to the assembler at runtime. this saves needing to
represent are ASM fragements as big functions with masses of function calls;
one can also have/use macro facilities;
...




(hmm... me thinking I should make my assembler/linker more publically
available?...).

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