At 01:55 PM 10/19/2001 -0400, Gregor N. Purdy wrote:
>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... :)

Ah, but I'd rather do it right the first time than have to redo it later, 
especially if the redoing is incompatible with what was done first. ;)

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

These would only be reserved for subroutine calls, which is pretty standard 
on CPUs with a reasonable number of registers. Normally a half-dozen or so 
float and general registers are marked as scratch, so the callee can mess 
with them as it wants. You say registers X-Y hold the parameters to the 
caller, register X holds the return value, register Y holds the status (if 
they're separate) and registers M-N are declared as scratch and the callee 
doesn't have to preserve them.

The only time these rules are in effect is when you make a sub call. Within 
the sub, you can do whatever you like with the registers.

Now, things are more interesting with Parrot, since we have at least one 
language that can potentially take and return a huge list of things, which 
is why I'm tending towards the "pass a list in P0, return a list in P0" way 
of doing things, or a separate stack of values. The biggest problem with a 
stack is that things are in reverse order, where passing in a list gets 
them to you in proper order.

                                        Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
[EMAIL PROTECTED]                         have teddy bears and even
                                      teddy bears get drunk

Reply via email to