From: Nathan F. <fr...@gm...> - 2008-11-19 22:06:47
|
On Wed, Nov 19, 2008 at 4:50 PM, Vitaly Mayatskikh <v.m...@gm...> wrote: > I'm compiling "low level" ray tracer written in lisp: > http://www.ffconsultancy.com/ocaml/ray_tracer/code/5/ray.lisp ... > but I want to see here such code: > > ; disassembly for RAY-SPHERE > ; 028588E3: F20F104E01 MOVSD XMM1, [RSI+1] ; no-arg-parsing entry point > ; 8E8: F20F105609 MOVSD XMM2, [RSI+9] > ; 8ED: F20F105E11 MOVSD XMM3, [RSI+17] > ; 901: F20F5CCC SUBSD XMM1, [RDX+1] > ; 905: F20F5CD5 SUBSD XMM2, [RDX+9] > ; 909: F20F5CDE SUBSD XMM3, [RDX+17] Ah, I think I see the problem, then. If I understand the code correctly, RSI and RDX are pointers to a double-float array. The VOPs are then generated to do: fetch RSI[0] fetch RSI[1] fetch RSI[2] fetch RDX[0] fetch RDX[1] fetch RDX[2] ...do subtractions... and there's no good way to fold those memory accesses into the VOPs that actually do the subtractions. (When we were talking about DESCRIPTOR-REGs earlier, those registers were assumed to hold tagged double-floats, not arrays of unboxed double-floats.) What you want to do is certainly desirable, but it's not going to be done by twiddling with the descriptions of the VOPs. >> > This is a sort of (declare (ignore r)). SBCL stops its build when >> > there is unused variables in vop. >> >> Ah, I didn't even look at the rest of your VOP. It's incorrect if >> you're not using R, then; X might be equal to R, but it might not. > > Ok, I have another question: VOP takes 2 args (`x' and `y') and returns > result in the same physical storage like `x' has (modifies state of > `x'). How can I describe it in VOP correctly? You can specify that you'd prefer if the first argument and the result share the same physical storage (that's what :TARGET does) and the register allocator will take that into account (and hopefully do the right thing!). But the VOP still needs to work correctly even if that preference isn't satisfied. -Nathan |