[Top][All Lists]

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

Re: wip-rtl native closure creation

From: Stefan Israelsson Tampe
Subject: Re: wip-rtl native closure creation
Date: Mon, 6 Aug 2012 19:46:34 +0200


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.


On Mon, Aug 6, 2012 at 11:32 AM, Andy Wingo <address@hidden> wrote:
On Sun 05 Aug 2012 17:19, Stefan Israelsson Tampe <address@hidden> 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.)


reply via email to

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