Gregor N. Purdy writes: > Need it *actually* stick them in the array? Or, could it > just provide an array-like interface to the underlying > registers? Thats cheaper, especially if not all args are > going to get accessed.
I don't think so. What if you wanted to make a closure over the array? Then the next time the array is accessed, the registers would be all different, and Bad Things would happen. > Explaining how such a thing works to an optimizer that > wants to know when registers are being accessed, on the > other hand... Or even a register allocator... > IIRC the conventions are set up in such a way that the > PMC would have to know the args prototype to know which > registers to use for each element of the array, whether > copying values from them or just providing an interface > to them. Good point. It might be possible, just for simplicity's sake, to put each PMC in one-by-one, and then flatten the overflow array into it. (Or even unshift all this onto the overflow array... but that adds a requirement on the capabilities of the overflow array). Then again, I'm looking for a nice way to specify the prototype as data, so we can get call context (the prototype of the return continuation). Unfortunately, context requires we know the class we're looking for, and class is a very language-dependent thing. Luke > > Regards, > > -- Gregor > > On Sat, 2003-09-20 at 21:17, Luke Palmer wrote: > > Steve Fink writes: > > > The callee side would then need to have a way of saying "...and all > > > the rest". So that would be > > > > > > .params PythonArray foo > > > > Or, perhaps we could have an ArgArray PMC, which, upon construction, > > would examine the registers as per the calling conventions, and stick > > all the arguments in the PMC. > > > > Luke > -- > Gregor Purdy [EMAIL PROTECTED] > Focus Research, Inc. http://www.focusresearch.com/
