>>>>> "rif" == rif <[EMAIL PROTECTED]> writes:
>> >>>>> "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.
rif> How many FP registers do I have total on x86? I guess I agree that
There are 8 FP registers.
rif> l2-distance-squared should only end up needing a couple more registers
rif> (basically one to store products and one to store the sum, with
rif> possibly another to handle the square, depending on whether I have a
rif> built in instruction to square a double-float number). Is there an
rif> easy way to look at the assembly to tell whether I'm out of floating
All of the FP registers in a disassembly look like <fp inst> ST, or
ST(i) for i in 0-7. You can also look at the trace file and grep for
FR[i], which is the FP register i. (Generate trace file via the
:trace-file option to compile-file.)
But it's difficult to tell, really, if you're out of registers because
sometimes cmucl will save a FP register on the stack for other
reasons.
rif> Yes, I meant (simple-array fixnum (*)). I agree that I get rid of
rif> array-dimensions compiler notes by including this; however, I find
rif> that it rarely ends up making the program noticeably faster.
Yes, that's probably true. But your program would probably run a
little faster if the compiler knew that the array has only one
dimension. Don't know if (aref a n) propagates the assumption that
the array a has 1 dimension to other parts of the code.
Ray
