Re: Managing the JIT

From: "BGB / cr88192" <cr88192@hotmail.com>
> "Armel" <armelasselin@hotmail.com> wrote in message


> however, the textual interface provides capabilities not available if
> direct
> function calls were used, such as using multi-pass compaction (AKA: the
> first pass assumes all jumps/... to be full length, but additional passes
> allow safely compacting the jumps).


why a binary-near interface could not do compaction? when I describe the API
with something like jit.move(ax,25), it does not preclude the usage of
higher level semantics such as jit.jump(label_id), and later write
jit.label(label_id), and finally write jit.end( ) to close the function
being compiled, optimizing all jumps and finalizing labels.


> granted, my internal code does not go about attempting nearly so nice an
> interface as asmjit (with a single function per instruction, ...), rather,
> the interface is a good deal more terrible...
>[...]
> void BASM_OutOpGeneric2(BASM_Context *ctx, int op, int w,
> char *lbl0, int breg0, int ireg0, int sc0, long long disp0,
> char *lbl1, int breg1, int ireg1, int sc1, long long disp1);
>[...]


asmjit is just having the "op" part into some other functions of a form
which helps the user avoid wrong calls that's all what I expect.


>[...]
> what does the binary interface buy you?...
> i=3;
> basm_print("mov rax, %d\n", i);


it is for too easy IMHO to write something which compiles but does not run.
jit.mov (rax, i) ensures me immediately at compile time that there is really
such an instruction, that I could not make a mistake while writing. it seems
less error prone to me.


> note that wrapping every single opcode with a function would likely be far
> more work than writing most of the assembler.


hehe, my place here is as a _user_ of a JIT not as a conceptor, i do not
care if they add more or less work.


> [...]
> the overal performance difference either way is likely to be small, as in
> this case, the internal processing is likely to outweigh the cost of
> parsing
> (figuring out which opcode to use, ...).


yes probably, parsing generated assembler is really easy (not real for ultra
good error reporting, no need for macro handling...).


Regards
Armel

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