On Mon 21 Jan 2013 19:28, Stefan Israelsson Tampe
writes:
> As I understood my reason for doing this was that many closures point to
> the same code fragment
Ah, I see. Yes indeed this may make sense. I'll keep it in mind.
Andy
--
http://wingolog.org/
Hi,
As I understood my reason for doing this was that many closures point to
the same code fragment
and If we compile one of those closures the others will not benefit. So
therefore I stored the native
code at the beginning of the rtl code fragment and used this mechanism. I
have not gotten this n
On Thu 09 Aug 2012 20:59, Stefan Israelsson Tampe
writes:
> DO you think that this will do as an initial patch to wip-rtl in order
> to introduce the possibility to
> execute native code or JIT:ed code. We reserve the first two indexes in
> the ip text area to fit
> a pointer to native code to b
Hi all,
The rtl native environment is close to a usable state for linux x86-64.
Most instructions have been translated to assembler and it remains to debug
them
and write test cases which will take some time.
Consider the simple code,
(define (f n)
(let loop ((n n) (s 0))
(if (eq? n 0
Hi,
DO you think that this will do as an initial patch to wip-rtl in order to
introduce the possibility to
execute native code or JIT:ed code. We reserve the first two indexes in the
ip text area to fit
a pointer to native code to be executed.
There is changes to two parts of the code
1. module/
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
12 matches
Mail list logo
