> Date: Fri, 12 Nov 2004 04:10:20 -0800 > From: Bill Coffman <[EMAIL PROTECTED]>
> > > And spilling? > > > > Well, I'm proposing a variable-sized register frame. With very little > > additions we could run with more then 32 registers per kind (there are a > > few bitmasks currently that would need adaptions, but not much). > > I think this is a great idea. So do I. Having a fixed number of registes is like having the C keywords register0 through registerN. All registers should be $Pn registers and let the guts deal with how that maps physically. I certainly don't care which $Pn register maps to which Pn register, should a PIR programmer ever care? As far as I can tell the only reason why a PIR programmer would even use Pn registers is for implicit arguments, leading me into my next point: I strongly feel that Leo was right to suggest removing implicit register arguments from opcodes. I responded to that email but somehow it didn't get to the list AFAICT. I can't think of any good reason or use case for implicit arguments. Can one be provided? From my experiences with Parakeet, it's just more weird, implicit stuff that I have to keep in my head that confuses new PIR programmers who look at my code. Since I'm on the box I might as well get it all out: I don't think unprototyped pcc calls should use the first 11 arguments in P registers and the rest in an array, again it just doesn't make any sense to me other than to violate DON (Don't Optimize Now, in tribute to Don Knuth). Just pass an array and be done with it. If the guts want to register-optimize arguments then fine, why does the PIR programmer have to do it by hand? (this is really an specific extension of the argument against implicit register usage) Unprototyped arguments are usually built dynamically at run time anyway or called in from an external language. I wager the performance benefit is miniscule to nothing compared to the contortious PIR code needed to pack and unpack arguments into registers, spill arguments into an array, avoid those 11 P regisers all the time, and the pressure it all puts on the register allocator. For prototyped calls I can (barely) see this as being useful, but not unprototyped. Fixed registers, implicit arguments, and calling contortions are "dead chickens" (coined, AFAIK, by Jim Fulton). They're the completely useless things you have to wave over the machine to get it to do what you want. The less dead chickens you have to wave over Parrot, the better. -Michel
