[Top][All Lists]

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

Storing JIT Code

From: Noah Lavine
Subject: Storing JIT Code
Date: Sun, 18 Jul 2010 22:01:36 -0400


Attached are some patches I made for storing JIT code associated with
objcode objects. These are based on some threads a few weeks ago in
which we discussed how to handle JIT code, with the eventual goal of
adding a JIT compiler to Guile (I'm working on it).

The goal is to have a piece of JIT code associated with each objcode
object. Another possibility would be to associate them with procedure
objects, but that was rejected because it would make the procedure
object 5 words long, which might mess up caching.

I've tried two ways to do this so far: putting the JIT code in a
struct scm_objcode and putting it in the SCM object that always wraps
one of those structs. I tried the first way first, but I hit problems
because strings of bytecode are expected to be valid C structs, and
adding a pointer would require leaving more space there, which would
leak abstractions. Therefore, these patches implement the second way.
(A possible third way would be to put the JIT code in a property.)

The first patch adds the extra slot to the SCM object and initializes
it to C's NULL. This required changing a few functions in objcode.c to
make the SCMs differently. Unfortunately, I also had to change all of
the statically-generated objcode objects in continuations.c,
control.c, gsubr.c, foreign.c, and smob.c, so the patch is quite long.

The second patch adds some infrastructure to the VM to call a dummy
JIT compiler, cache its results, and run the resulting code if any is
generated. I set up a return convention so that the JIT compiler can
fail to compile things and the VM will run as usual, which I think
will be useful while there is a partially-complete compiler. (Although
I'm not convinced I've chosen the best values for it. Currently a NULL
jitcode means we've never tried to compile, and an SCM_BOOL_F means we
tried and failed, and therefore won't try again. Are there better

I'm afraid these patches will require the set of small fixes I just
emailed, because one of the diffs modifies a comment that was added in
one of those patches. I believe the first patch is complete, but the
second patch is quite rough still. What do you think of them?


Attachment: 0001-Add-JIT-pointers.patch
Description: Binary data

Attachment: 0002-Add-JIT-Infrastructure.patch
Description: Binary data

reply via email to

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