On Fri, 19 Oct 2001, Dan Sugalski wrote: > At 01:24 PM 10/19/2001 -0400, Gregor N. Purdy wrote: > >James -- > > > > Should we have bsr(i|ic, i|ic), that jumps to $1, with the return > > address below the $2 arguments? Similarly, should we have ret(i|ic), > > that rotates the return address out from under $1 arguments and then > > returns to it? > > Nope. For a number of reasons, the biggest being that we're not returning > our return values on the stack. :) > > > > OTOH, we could keep our current ABI, and pop the return address into an I > > > register, and then push it and ret, or jmp to it. > > > >The return address is a pointer, which doesn't necessarily fit in an IV, > >I believe. I played with doing this first, but didn't like having to use > >a register for it. If we wanted registers to be part of the calling > >convention, we should just say so, but again we run into the question of > >which type of register to use. > > I'm currently leaning either towards returning values in registers > [PSIN][0-4] with the total number of each type in register I0 somehow, or > as arg stack that's separate from the call stack. The latter is probably > the better way to go, but it's got more overhead in some ways. It'd make > interfacing with RPN languages easier, though. >
I was in the middle of writing up something on this topic.. I'm still working on the details, so I'll summarize. The more out-of-band data the better.. It's faster (no munging an all in one stack), more efficient (don't have to abstract it's type), and we're not limited like some hardware is (e.g. having a single stack segment). Most of my bias is based on a paper on stack-based machines presented by someone else earlier in this mailing list. It was a good paper, though somewhat dated. The only problem with having out-of-band return addresses is syncing up with the stack (unrolling it for exceptions of frame-analysis). I was working on a concept that used segregated stack-frames for the parameter stack, with the stack frame header referencing the "top-of-return-address stack". Alternatively, the return-address-stack could contain a reference into the parameter stack(s). The latter would be easier for unrolling, but makes the pushed value a little more complex. I'm not particular on the details, though I'm still working on them, but I definately think out-of-line return addresses are "good thing"(tm). -Michael
