Re: compile-rtl

[Andy Wingo]

On Sun 14 Oct 2012 17:13, Stefan Israelsson Tampe <address@hidden> writes:

> potential memory leaks. To let it be as it is designed right now, will
> mean that it is very difficult looking at the scheme code to see what
> will be protected from gc or not.

Explicit clearing is much better than a stack pointer.  We can be much
smarter about it.

> Now when we are tail-calling in rtl, we just fill the argument slots
> with the new function arguments directly and then tail-call by filling
> in
> number of arguments and function. This is very smart and just some
> simple features added would mean that a lot of translation
> from one memory location to the other is skipped. I really like how the
> rtl code handle this but there is an expense. It complicates life a
> little
> when we overwrite arguments that are used in the calculation of other
> arguments. I'm working on how to handle this but I just wanted to point
> out how nice this design choice is.

Thanks!  In general at the end you have a parallel register move (or
parallel assignment), which has a number of standard solutions out
there.

> call's, here currently we send a list of register positions to the call
> function and the call function itself will copy those to the argument
> fields. This is the opposite
> of the tail-call, in a case like (f 1 3) you will create two temporary
> variables and copy them later on to the argument position. Here I would
> like to change the 
> semantic so that we fill in the arguments directly just like in the
> tail-call.

We can't do this unless we reintroduce a stack pointer, I don't think;
and anyway reopening the hole for the in-progress frame is pretty nasty
for the runtime (the backtrace code in particular).  Dunno.  I'm
hesitant to change this.

> Also, I would like to use the end of the stack region to compute the
> function frame. Well even if we use the end of the full frame we will
> save one move per argument which is nice.

This is possible I guess, but again makes tooling a bit difficult.

> 4.
> Return values.
> We talked about this before and there is some concerns how to make this
> fast. I would like to skip the complication by simply put the return
> values in the
> argument positions to the function. Also the number of arguments is
> mediated to the reciever. I would like to skip the mv-return slot

Have you been working off of wip-rtl after the commit, "remove
return_loc, instead put mv returns on the stack" ?  Does that not solve
the issue for you?  After that commit, there will be no more MVRA
(though it is still there while the VM is in a transitional state).

Andy
-- 
http://wingolog.org/