Dan -- > > 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. :)
Well, until something better comes along, Jako subroutines return *their* 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. FWIW, I'd rather not dedicate registers to special uses at the Parrot level. Jako reserves [INPS]0 for temporaries, but that is at its discretion, not dictated by Parrot (and I like it that way :). I was wishing for separate data and address stacks when I was writing the Jako calling convention stuff, but I can live with the rotate solution. If the choices come down to reserved registers or separate stacks, though, I'm squarely in the separate stacks camp. Regards, -- Gregor
