Re: Managing the JIT

"Armel" <armelasselin@hotmail.com>
Fri, 31 Jul 2009 10:23:43 +0200

          From comp.compilers

Related articles
[3 earlier articles]
Re: Managing the JIT armelasselin@hotmail.com (Armel) (2009-07-25)
Re: Managing the JIT herron.philip@googlemail.com (Philip Herron) (2009-07-27)
Re: Managing the JIT cr88192@hotmail.com (BGB / cr88192) (2009-07-27)
Re: Managing the JIT cr88192@hotmail.com (BGB / cr88192) (2009-07-28)
Re: Managing the JIT armelasselin@hotmail.com (Armel) (2009-07-29)
Re: Managing the JIT cr88192@hotmail.com (BGB / cr88192) (2009-07-30)
Re: Managing the JIT armelasselin@hotmail.com (Armel) (2009-07-31)
Re: Managing the JIT barry.j.kelly@gmail.com (Barry Kelly) (2009-08-01)
Re: Managing the JIT cr88192@hotmail.com (BGB / cr88192) (2009-08-02)
Re: Managing the JIT cr88192@hotmail.com (BGB / cr88192) (2009-08-02)
Re: Managing the JIT ademakov@gmail.com (Aleksey Demakov) (2009-08-07)
Re: Managing the JIT cr88192@hotmail.com (BGB / cr88192) (2009-08-08)
| List of all articles for this month |

From: "Armel" <armelasselin@hotmail.com>
Newsgroups: comp.compilers
Date: Fri, 31 Jul 2009 10:23:43 +0200
Organization: les newsgroups par Orange
References: 09-07-079 09-07-093 09-07-108 09-07-113 09-07-117
Keywords: incremental, code
Posted-Date: 01 Aug 2009 16:48:57 EDT

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



Post a followup to this message

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