Re: compile-rtl

2013-01-27 Thread Andy Wingo
On Sat 26 Jan 2013 13:28, Stefan Israelsson Tampe writes: > Andy Wingo writes: > >>> 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 an

Re: compile-rtl

2013-01-26 Thread Stefan Israelsson Tampe
Andy Wingo writes: >> 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 transl

Re: compile-rtl, II

2013-01-21 Thread Stefan Israelsson Tampe
On Mon, Jan 21, 2013 at 6:39 PM, Andy Wingo wrote: > On Mon 15 Oct 2012 16:05, Stefan Israelsson Tampe > writes: > > > (arg1, return-address, old-frame, program, arg2 ...) > > > > This way we do not need to copy the program field at a tail call > > What would you do for 0 arguments? > > I would

Re: compile-rtl

2013-01-21 Thread Stefan Israelsson Tampe
(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 addr

Re: compile-rtl, II

2013-01-21 Thread Andy Wingo
On Mon 15 Oct 2012 16:05, Stefan Israelsson Tampe writes: > (arg1, return-address, old-frame, program, arg2 ...) > > This way we do not need to copy the program field at a tail call What would you do for 0 arguments? > Also another kind of difficulty will arise, many instructions only > take a

Re: compile-rtl

2013-01-21 Thread Andy Wingo
On Sun 14 Oct 2012 17:13, Stefan Israelsson Tampe 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.

compile-rtl

2012-10-14 Thread Stefan Israelsson Tampe
Hi, I'm right now trying to port compile-glil to compile-rtl and I would say that what's hindering me is what design choices to take? 1. The main problem is that we do not have a stack pointer the same way as before. Of cause we still need to store temporary values and we will simply h