wip-rtl native closure creation

wip-rtl native closure creation

[Stefan Israelsson Tampe]

[-- Attachment #1: Type: text/plain, Size: 786 bytes --]

Hi,

I was thinking how to mix rtl-VM and native compilation with respect to
closure creation

currently in the code we layout the program as

((nfree :16 | flags:8 | ?:7 | tag:0), code, freevar1 ....)

Then at closure creation we just set first slot, the code to point to a
relative adress relative
ip e.g. we just need 24 bits, and finally the free-vars is handled.

The thing to think of here is how to introduce a reference to native code,
if we add an extra slot
in the program data structure as currently down in the old program (not rtl
programs) definition, then
we must do some heavy magic to map vm-code to native code. Probably it is
best to have the first
qword / dword in the code to be 0 or the native adress e.g. I propose to
add that feature to the rtl-branch.

/Stefan

[-- Attachment #2: Type: text/html, Size: 853 bytes --]

Re: wip-rtl native closure creation

[Andy Wingo]

On Sun 05 Aug 2012 17:19, Stefan Israelsson Tampe <stefan.itampe@gmail.com> writes:

> Probably it is best to have the first qword / dword in the code to be
> 0 or the native adress e.g. I propose to add that feature to the
> rtl-branch.

Good question!  Given the different tradeoffs, that seems workable.
Another possibility would be to use a different TC7 for native
procedures.  After all, the only calls we need to make cheaply are
native->native and bytecode->bytecode, and the rest can go through a
general dispatch loop (possibly with inline caching).  WDYT?  (Also note
that RTL words are 32 bits wide, which may or may not be sufficient for
native code pointers.)

Andy
-- 
http://wingolog.org/

Re: wip-rtl native closure creation

[Sjoerd van Leent Privé]

On 06-08-12 11:32, Andy Wingo wrote:
> On Sun 05 Aug 2012 17:19, Stefan Israelsson Tampe <stefan.itampe@gmail.com> writes:
>
>> Probably it is best to have the first qword / dword in the code to be
>> 0 or the native adress e.g. I propose to add that feature to the
>> rtl-branch.
> Good question!  Given the different tradeoffs, that seems workable.
> Another possibility would be to use a different TC7 for native
> procedures.  After all, the only calls we need to make cheaply are
> native->native and bytecode->bytecode, and the rest can go through a
> general dispatch loop (possibly with inline caching).  WDYT?  (Also note
> that RTL words are 32 bits wide, which may or may not be sufficient for
> native code pointers.)
>
> Andy
Wouldn't it be feasible in the future that there might be, because of 
more memory, other designs, such as caching, which create much more 
closures than current designs? I don't know, but on 64-bit platforms 
(and perhaps even architectures with a larger bus), it seems to me that 
it is necessary to stick to this bus length.

Re: wip-rtl native closure creation

[Noah Lavine]

I haven't looked at the RTL program structure, but adding a new field
is basically what I did with the non-RTL program structure when I
worked on JIT there.

However, in that case we could still keep everything under 4 words. I
don't know if that will work here.

Noah

On Mon, Aug 6, 2012 at 5:39 AM, Sjoerd van Leent Privé
<svanleent@gmail.com> wrote:
> On 06-08-12 11:32, Andy Wingo wrote:
>>
>> On Sun 05 Aug 2012 17:19, Stefan Israelsson Tampe
>> <stefan.itampe@gmail.com> writes:
>>
>>> Probably it is best to have the first qword / dword in the code to be
>>> 0 or the native adress e.g. I propose to add that feature to the
>>> rtl-branch.
>>
>> Good question!  Given the different tradeoffs, that seems workable.
>> Another possibility would be to use a different TC7 for native
>> procedures.  After all, the only calls we need to make cheaply are
>> native->native and bytecode->bytecode, and the rest can go through a
>> general dispatch loop (possibly with inline caching).  WDYT?  (Also note
>> that RTL words are 32 bits wide, which may or may not be sufficient for
>> native code pointers.)
>>
>> Andy
>
> Wouldn't it be feasible in the future that there might be, because of more
> memory, other designs, such as caching, which create much more closures than
> current designs? I don't know, but on 64-bit platforms (and perhaps even
> architectures with a larger bus), it seems to me that it is necessary to
> stick to this bus length.
>

Re: wip-rtl native closure creation

[Andy Wingo]

On Mon 06 Aug 2012 11:39, Sjoerd van Leent Privé <svanleent@gmail.com> writes:

> Wouldn't it be feasible in the future that there might be, because of
> more memory, other designs, such as caching, which create much more
> closures than current designs? I don't know, but on 64-bit platforms
> (and perhaps even architectures with a larger bus), it seems to me that
> it is necessary to stick to this bus length.

I think the short answer is "no".  The long answer: although in the
execution of a program there may be a practically unbounded number of
closures, there is only a finite number of source locations, and
multiple closures for a given source location share code.  (Modulo
optimization and inlining and such things.)

So a 32-bit relative offset from a compilation unit's bytecode to native
code will be sufficient for at least, I dunno, a decade or so -- until
maybe we don't have bytecode at all any more.

Andy
-- 
http://wingolog.org/

Re: wip-rtl native closure creation

[Andy Wingo]

On Mon 06 Aug 2012 13:44, Noah Lavine <noah.b.lavine@gmail.com> writes:

> I haven't looked at the RTL program structure, but adding a new field
> is basically what I did with the non-RTL program structure when I
> worked on JIT there.

The difference is that with the stack vm, there are objcode objects on
to which you can put a pointer.  In the RTL VM there are only code
pointers.

Andy
-- 
http://wingolog.org/

Re: wip-rtl native closure creation

[Stefan Israelsson Tampe]

[-- Attachment #1: Type: text/plain, Size: 1814 bytes --]

Hi,

When code is both VM and native it's nice to be able to have both code
blocks as a unit because then
we can freely compile a function without needing to do graph analysis. It
simply makes the life easier to maintain the two setups. And incrementally
compile to native on a per uses base and not in one go very much like JIT
ing. Also the overhead on the VM side is low but the native execution will
of cause be a
little bit slower because of an extra indirection. I don't expect the
slowdown to be too bad though. Perhaps we could mark the beginning of a
code block in a program as

0     -> the rest of the vector is VM code
1     -> the rest of the vector is Native code
addr -> there is native code at the addr indirection

Then we can skip the expensive extra inderection for native code when
suitable.
To note here I assume that picking a[0],a[1] is less expensive then
a[0],*a[0].

At some stage we may leave the VM and perhaps enter into a Native only
mode. Then we can restructure.

/Stefan

On Mon, Aug 6, 2012 at 11:32 AM, Andy Wingo <wingo@pobox.com> wrote:

> On Sun 05 Aug 2012 17:19, Stefan Israelsson Tampe <stefan.itampe@gmail.com>
> writes:
>
> > Probably it is best to have the first qword / dword in the code to be
> > 0 or the native adress e.g. I propose to add that feature to the
> > rtl-branch.
>
> Good question!  Given the different tradeoffs, that seems workable.
> Another possibility would be to use a different TC7 for native
> procedures.  After all, the only calls we need to make cheaply are
> native->native and bytecode->bytecode, and the rest can go through a
> general dispatch loop (possibly with inline caching).  WDYT?  (Also note
> that RTL words are 32 bits wide, which may or may not be sufficient for
> native code pointers.)
>
> Andy
> --
> http://wingolog.org/
>

[-- Attachment #2: Type: text/html, Size: 2381 bytes --]