Date: Thu, 25 Apr 2013 11:25:43 -0700 From: Matt Birkholz <m...@birkholz.chandler.az.us>
The rest of the code keeps flonums in short flo:vectors (points, matrices). The LAP for procedures like 3d-transform! (below) looks nice and tight, not even an interrupt check(!). (But what are the three float->object instructions about? Can I punt them?) I'd hazard a guess that it's because you stored a flonum in a local variable: (let ((x (flo:...))) ... (flo:... x ...) ...) LIAR stores every local variable in the uniform object representation on the stack, so that means heap allocation for a flonum. You can work around this by asking SF to integrate the local variable and hoping LIAR's RTL CSE will take care of the code duplication: (let ((x (flo:...))) (declare (integrate x)) ... (flo:... x ...) ...) It is, of course, up to you to ensure that the right-hand side of the LET is movable -- that is, it has no side effects so that it can be evaluated multiple times, and it will yield the same value later. Also, please consider fine-grained NO-TYPE-CHECKS/NO-RANGE-CHECKS declarations -- only in scopes where you have meticulously proven that the type and range checks are guaranteed not to fail. If you'd like some code to handle floating-point vector and matrix arithmetic, I wrote some a while ago and put it at <http://mumble.net/~campbell/tmp/mit-matrix.scm> <http://mumble.net/~campbell/tmp/mit-vector.scm> It doesn't specialize arithmetic for fixed sizes of objects (e.g., 3x3 matrices in particular) but it is careful to do type and range checks outside inner loops and to avoid heap allocation. By the way, you don't need to look at the LAP to find and destroy cases of FLOAT->OBJECT -- the RTL exposes that too and is much easier to read. _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
