unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: guile-devel@gnu.org
Subject: Re: A Working (but Minimal) JIT
Date: Wed, 27 Oct 2010 23:10:36 +0200	[thread overview]
Message-ID: <8739rrwddf.fsf@gnu.org> (raw)
In-Reply-To: AANLkTimGPtG18P4w6K6BggU1ppm38a7f7HXozDS0FMGS@mail.gmail.com

Hello Noah!

Noah Lavine <noah.b.lavine@gmail.com> 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
me!

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

Thanks,
Ludo’.




  parent reply	other threads:[~2010-10-27 21:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-22  4:29 A Working (but Minimal) JIT Noah Lavine
2010-10-22 21:46 ` Phil
2010-10-27 21:17   ` Ludovic Courtès
2010-10-27 21:10 ` Ludovic Courtès [this message]
2010-10-27 22:53   ` Noah Lavine
2010-11-02 22:51     ` Ludovic Courtès
2010-11-20 13:37 ` Andy Wingo
2010-11-28 20:56   ` Noah Lavine
2010-11-29 21:25     ` Andy Wingo
2010-12-02  3:58       ` Noah Lavine
2010-12-06 22:06         ` Andy Wingo
2010-12-06 22:53           ` Noah Lavine
2010-11-28 20:58   ` Noah Lavine
2010-11-28 22:36     ` Ludovic Courtès
2010-11-29  7:18       ` Ken Raeburn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8739rrwddf.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guile-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).