|From:||Stefan Israelsson Tampe|
|Date:||Mon, 21 Jan 2013 20:01:38 +0100|
On Sun 14 Oct 2012 17:13, Stefan Israelsson Tampe <address@hidden> writes:Explicit clearing is much better than a stack pointer. We can be much
> 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.
smarter about it.
> Now when we are tail-calling in rtl, we just fill the argument slotsThanks! In general at the end you have a parallel register move (or
> with the new function arguments directly and then tail-call by filling
> 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
> 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.
parallel assignment), which has a number of standard solutions out
> call's, here currently we send a list of register positions to the callWe can't do this unless we reintroduce a stack pointer, I don't think;
> 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
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 theThis is possible I guess, but again makes tooling a bit difficult.
> function frame. Well even if we use the end of the full frame we will
> save one move per argument which is nice.
> 4.Have you been working off of wip-rtl after the commit, "remove
> 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
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).
|[Prev in Thread]||Current Thread||[Next in Thread]|