Re: [MIT-Scheme-devel] A tellurion for the faithful.

[Taylor R Campbell]

   Date: Thu, 25 Apr 2013 11:25:43 -0700
   From: Matt Birkholz <address@hidden>

   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.