> >>>>> "rif" == rif <[EMAIL PROTECTED]> writes: > > rif> In this case, it seems like your out-of-registers explanation is > rif> correct. l2-distance-squared is an inlined function that seems like > rif> it'd use quite a few floating point registers. Furthermore, if I > > I made up an l2-distance-squared function of my own, since you never > sent one. I still only see a couple for FP registers.
How many FP registers do I have total on x86? I guess I agree that l2-distance-squared should only end up needing a couple more registers (basically one to store products and one to store the sum, with possibly another to handle the square, depending on whether I have a built in instruction to square a double-float number). Is there an easy way to look at the assembly to tell whether I'm out of floating point registers? I've always meant to learn x86 assembly, but I haven't gotten to it yet. > In this case, you might want to investigate block compilation. You > won't have to inline l2-d-s, but I think it allows the compiler to > arrange it so that args and results don't have to be boxed. But check > the User's manual to be sure. I don't see how this could technically help over inlining in terms of the number of registers I'd need. I see how it could reduce total code size, because I wouldn't have to inline the function, but the function is only used a few times total. > rif> Note that in AllegroCL the situation is somewhat different, in that > rif> it's crucially important to declare that your arrays are 1D: > > rif> (declare (type (simple-array fixnum *) foo)) > > This says FOO is a simple-array of fixnums, but any number of > dimensions. Did you really mean (simple-array fixnum (*)) which means > FOO is a 1-D array of fixnums? Yes, I meant (simple-array fixnum (*)). I agree that I get rid of array-dimensions compiler notes by including this; however, I find that it rarely ends up making the program noticeably faster. Cheers, rif
