guile-devel
[Top][All Lists]
Advanced

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

Re: Troubles with Objcode and Storing JIT Pointers


From: Noah Lavine
Subject: Re: Troubles with Objcode and Storing JIT Pointers
Date: Sun, 4 Jul 2010 13:43:07 -0400

Problems fixed - sorry for the confusion. I will send a new patch to
guile-sources which corrects all of these issues.

Noah

On Sat, Jul 3, 2010 at 2:28 PM, Noah Lavine <address@hidden> wrote:
> Hello,
>
> I just sent two patches which start to implement this to
> address@hidden (The first patch is actually a small
> documentation change, which I made only so I could rewrite it with
> updated documentation in the second patch.)
>
> The patch works as you described - SCM objcodes become five-word
> objects, and all of the references get updated. I also had to change
> all of the files that include static objcodes, which is why there are
> changes to continuations.c, control.c, foreign.c, gsubr.c, and smob.c.
>
> Unfortunately, I've hit a snag that I don't understand - if you try to
> build it, you will see that control.c encounters an error in a
> function that isn't changed by the patch. I am hoping that someone who
> understands Guile's build system more than I do could look at that,
> because I don't know what's happening.
>
> There is one other issue with the patch that needs discussion, which
> is what to initialize the extra cells to. Currently they're
> initialized to NULL, and a comment describes a possible convention for
> storing JIT code with them, but I'm not convinced it's the best way.
> In particular, using an SCM symbol like 'no-jitcode for empty pointers
> would be more self-documenting, but I wasn't sure if it would work in
> statically-generated objcodes.
>
> Thanks
> Noah
>
> On Tue, Jun 22, 2010 at 3:03 PM, Andy Wingo <address@hidden> wrote:
>> On Tue 22 Jun 2010 00:23, Noah Lavine <address@hidden> writes:
>>
>>> If I may ask, do you already have patches or a git branch that adds [a
>>> native code slot to objcode]? If so, what are you doing about the
>>> embedded objcode issue? (Changing the bytecode to leave room for it,
>>> or hiding the slot in the C code?)
>>
>> I do not have a patch, no. Feel free to implement :) Having not
>> implemented it, I do not know exactly what's needed, but I would not put
>> it in what is the struct scm_objcode, rather in the SCM value that
>> includes the objcode.
>>
>> I don't know if we can somehow fit this in a "double cell" or if we need
>> to have a five-word object (see scm_words ()).
>>
>> Andy
>> --
>> http://wingolog.org/
>>
>



reply via email to

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