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
On Mon 06 Aug 2012 13:44, Noah Lavine 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
On Mon 06 Aug 2012 11:39, Sjoerd van Leent Privé 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 archite
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 A
On 06-08-12 11:32, Andy Wingo wrote:
On Sun 05 Aug 2012 17:19, Stefan Israelsson Tampe
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, tha
On Sun 05 Aug 2012 17:19, Stefan Israelsson Tampe
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 possibil
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
