[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A Working (but Minimal) JIT

From: Ludovic Courtès
Subject: Re: A Working (but Minimal) JIT
Date: Wed, 27 Oct 2010 23:10:36 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Hello Noah!

Noah Lavine <address@hidden> writes:

> After not emailing for a while, I have some good news: a JIT engine is 
> working!

Woow, neat!  :-)

> The biggest change since the last version is that I switched from
> Lightning to libjit. This was mostly because I realized that if I was
> going to use Lightning, I would need to implement a register
> allocator, and seemed like a bad idea when libjit already had one.
> libjit also solved a memory allocation problem which had been causing
> trouble in the Lightning version, and in general has a very
> easy-to-use interface, so I think this is a good way to go.

Interesting.  Dealing with end-of-buffers situation is indeed tricky
with lightning, and register allocation is lacking (I thought this
wouldn’t necessarily be a problem because we can do a reasonable job
with a fixed set of statically allocated registers.)

> First, we would need to figure out how to integrate this into the VM
> more. Right now it's only activated in the 'mv-call' instruction, but
> it should be activated by all of the instructions.

I think it’s OK to jit just at call time at first.  There could be a
call counter on procedures, which would allow you to determine whether
it’s worth jitting (i.e., only jit a procedure after it’s been call at
least N times.)

> Second, the compiler would need to be extended to handle more VM
> opcodes.

My plan was to use macro magic to turn each ‘VM_DEFINE_INSTRUCTION’ into
a function definition, except for the ‘call’ instructions and similar.
Then all the jit’d code would do is call these functions, so jitting
would be quite simple.  Still, it’d remove one layer of interpretation,
which could lead to performance gains.

Then instructions could gradually be rewritten in libjit assembly, but
that takes time.

> So, this is a possible way to get a JIT engine in Guile. What do
> people think of it?

I haven’t looked at the code yet, but it surely sounds interesting to

I’m looking forward to the next news bulletin.  ;-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]