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

[Matt Birkholz]

Oops.  I thought I pulled the trigger on this email days ago.  I found
it again after I came across a discussion of flo:vectors and flonum
consing in, of all places, the User Manual!  RTFM indeed.

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.

> From: Taylor R Campbell <address@hidden>
> Date: Fri, 15 Oct 2010 05:14:58 +0000
> 
> [...]
> Note that control does not proceed in compiled Scheme code until the
> next interrupt check -- instead, control immediately transfers to a
> microcode error handler in the runtime.
> 
> This is all how MIT Scheme already works. [...]

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?

All is answered by The Code, of course, so I thank you for indulging
me.  Please do not feel obliged to answer.  I am just trying to follow
the example set by St.Feynman. :-)

    It's called a briefing, but it wasn't brief: it was VERY intense,
    very fast, and very complete.  It's the only way I know to get
    technical information quickly: you don't just sit there while they
    go through what THEY think would be interesting; instead, you ask
    a lot of questions, you get quick answers, and soon you begin to
    understand... --_What Do YOU Care What Other People Think?_

> What we don't have is a performant way to read IEEE 754 floating-point
> values in from the network or write them to a file or anything --
> floating-point vectors are useless for that.

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

> You can at least make the procedure a little conciser, and take
> responsibility for checking types and ranges yourself.

Thanks!  Those two declarations, (no-type-checks) and
(no-range-checks), produced some nice RTL.  (f i) turned out just as I
had hoped.

  (assign (register #x56) (float-offset (offset-address (register #x19) 
(machine-constant 1)) (machine-constant 3)))
  (assign (register #x57) (flonum-2-args flonum-multiply (register #x1d) 
(register #x56) #f))
  (assign (register #x66) (float-offset (offset-address (register #x19) 
(machine-constant 1)) (machine-constant 4)))
  (assign (register #x67) (flonum-2-args flonum-multiply (register #x2d) 
(register #x66) #f))
  (assign (register #x76) (float-offset (offset-address (register #x19) 
(machine-constant 1)) (machine-constant 5)))
  (assign (register #x77) (flonum-2-args flonum-multiply (register #x3d) 
(register #x76) #f))
  (assign (register #x79) (register #x67))
  (assign (register #x7b) (flonum-2-args flonum-add (register #x79) (register 
#x77) #f))
  (assign (register #x7d) (register #x57))
  (assign (register #xc1) (flonum-2-args flonum-add (register #x7d) (register 
#x7b) #f))

> 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. :-{
:-)

> Here's some code I wrote when I last needed to do reasonably fast
> floating-point computation and I/O -- most of the important operations
> (e.g., matrix multiplication) do not incur intermediate consing and
> are totally open-coded when compiled:
> 
> <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?