Dan -- > 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. ;)
I would, too. But I view Jako is being a sort of test bed for what our choices at the Parrot level do to language implementers. So, Jako is intended to track the current-best-practice, as it changes. That means I expect, for example, to re-implement the calling convention stuff a few times. Heck, Jako had subroutines before we had bsr! > >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. I agree that a HLL that has a list type should use that list type for its arg and return passing. But, low level stuff (like Jako is currently) should still have access to a reasonable no-pmc-required calling convention, IMO. Regards, -- Gregor
