On Sun 14 Oct 2012 17:13, Stefan Israelsson Tampe <stefan.ita...@gmail.com> 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/
