On Thu, 2004-04-29 at 05:43, Dan Sugalski wrote: > While it's much nicer to reorder the parameters, I left them in that > way on purpose. Once you start reordering in and out parameters then > you get into multiple joined parameters (buffer pointers and lengths) > and then it starts (well, continues) to get really nasty.
Would following Tim's suggestion to put retval in the first return register and the out parameters in subsequent registers be more to your liking? > I'm not opposed to a scheme, mind, but I wonder if maybe we'd be > better off leaving NCI what it is (really primitive) and building a > tool to do the cleanup of the parameters that generates bytecode to > do it instead. Unless we go with Leo's other idea of passing in a struct containing out parameters, there's currently no way to do this from bytecode. By the time you're back to bytecode from the thunk in nci.c, one of your out parameters is gone forever, if a collision occurred. The struct approach has merit in that it keeps the simple case simple and requires few, simple changes to nci.c (if at all). It has a drawbacks though. It increases the differences between the function signatures for the native calls and the setup for Parrot calls in a way that's visible to users. (Oh, it wants an int pointer and a string pointer, but I have to pass one thing, a pointer to a struct containing an int and a string.) Building structs to pass around is currently very verbose and my least favorite part of NCI. (Again, it's not nearly as tricky as XS, for which I'm very grateful.) On the other hand, this is likely an odd case. It only shows up when there's a return value of the same register type as an out parameter in the first parameter register. That's a bit of a coincidence. It still would be nice to have that work deliberately, not accidentally. -- c
