Re: compile-rtl

[Stefan Israelsson Tampe]

On Mon, Jan 21, 2013 at 6:32 PM, Andy Wingo <address@hidden> wrote:

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.

You may be right here, But still I had a try of this and coded some examples with a different

kind of stack pointer that I expect to be really interesting. Please dig a little further in the backlog 

to find an email discussing this. We can take up the discussion then. 

 

> 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.

I have coded allocation that allocates directly to the tail call slots e.g. inf needed move away the

affected slots to some safe address, so the generated RTL code will short circut the move to the tail

call addresses. I must also mention that my compile-rtl code is built ontop of compile-glil (In order to

get an understanding of all tree-il finesses) And is a bit hacky. I expect a purer verions to be coded in 

the end. Noha have started a try to do this. Meanwhile I can port over any good ideas from my endavour.

 

> 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.

In my current code I follow your approach but have some flags where I can add

this feature if we like to investigate this.  To note is that I simulate the stack pointer in

the rtl register generation, but it never enters explicitly in the code. I do use some kind of

lightweight bursty stack register mechanism that is pretty cool concept. But as said before 

that is a mail further down in the backlog. Unfourtunately I'm pretty ignorant of the runtime

issues and Have to educate myself on this issue before I can answer any better. Good point!

 

> 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.

I did not continue further down this path

 

 

> 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).

I think I might have taking your idea and implemented it fully in a patched rtl vm.

I really would like to stress that if you though the aschm stuff is craze, the compile-rtl

code is crazy^2. But it's a good testbed to try out some context ANd I learned a lot!

 

Andy
--
http://wingolog.org/