Re: [MIT-Scheme-devel] floating-point environment

[Taylor R Campbell]

   Date: Fri, 22 Oct 2010 10:54:13 -0700
   From: address@hidden (Matt Birkholz)

   I think the FM could use a word or two (like 'no-type-checks' and
   'no-range-checks'), maybe something along the lines of our example.

Go ahead!

   The trap handler can work backwards, finding a continuation BEFORE the
   run of code that signaled?  The "next interrupt check" would be AFTER,
   possibly after unwinding the stack and getting FAR away from the cause
   of the exception?

When the machine executes a floating-point instruction that traps, it
packages up its complete state (program counter, stack pointer, and
other registers) and passes that to the SIGFPE handler.  MIT Scheme's
SIGFPE handler looks at the saved program counter and tries to find
the compiled block it was in.  Then the SIGFPE handler pushes a frame
on the stack (a `hardware trap frame') with the information it found,
and signals a condition in Scheme.

If that condition makes its way to the debugger, the debugger will
show you what compiled block the program counter was in, and it will
heuristically try to find the topmost return address that was on the
stack when the machine trapped, as well as the rest of the
continuation from there on down.

Note that if the machine traps in a compiled block, control never
reaches the next interrupt check in that block -- it immediately
transfers to the SIGFPE handler in the microcode, and from there to a
condition handler in the runtime system, and from there perhaps to the
debugger, but never past the instruction that trapped.  Also, the same
procedure happens with other signals, too, such as SIGSEGV for memory
references to unmapped pages.

   You want port ops that read/write standard binary interchange formats,
   any length?  Thus a fixed-length-float type is useless? ?

In communicating between programs or storing data on disk, one must
sometimes take, say, eight octets from the network or the disk and
interpret them in the little-endian double-precision IEEE 754 format,
to obtain a Scheme object satisfying REAL?.  We have no efficient way
to do that at the moment.

   > LIAR's type and range checking is pretty hokey

   I don't mind being responsible.  I like a KISS (predictable) code
   generator.  You are thinking of some kind of "checking" smarter than
   me, aren't you. :-{
   :-)

What I meant by the above is that LIAR takes no effort to omit
needless type checks, so you have an option to check all types (and
throw out unboxed flonums) or check none (and throw out safety).  For
example, for (IF (PAIR? X) (CAR X) 'FOO), LIAR will generate two PAIR?
tests.  Similarly, for (FLO:* (FLO:+ A B) C), LIAR will generate a
type check for whether the result of (FLO:+ A B) is a flonum.  Not
only is such a type check unnecessary, but it forces the value of
(FLO:+ A B) to be boxed, too.

(In any case, I don't think there's much about LIAR that satisfies
KISS.)

   > <http://mumble.net/~campbell/tmp/mit-matrix.scm>
   > <http://mumble.net/~campbell/tmp/mit-vector.scm>
   > <http://mumble.net/~campbell/tmp/mit-flonum-bits.scm>
   > 
   > (The last is a sleazy hack I'd like to replace by new primitives.)

   Very nice.  The "sleaze" seems well confined.  You do not feel they
   are fit for general use?

Well, I suppose using the code I already wrote is easier than writing
new primitives and implementing new open-codings for them for every
architecture.  Of course, it doesn't help for the single-precision
floating-point format.