> From: Taylor R Campbell <campbell@mumb...>
> Date: Thu, 16 Jun 2011 18:38:12 +0000
>
>    Date: Thu, 16 Jun 2011 10:11:28 -0700
>    From: Matt Birkholz <matt@birk...>
>
>    [...]  But doesn't our shiny new floenv.scm takes care of all
>    this, withOUT going behind libc's back?  Can we punt the ancient
>    fpu inits in microcode/cmpauxmd/i386.m4 and x86-64.m4?  (Dare me
>    to try it?)
>
> Maybe.  I'm not sure in what floating-point environment a restored
> band would start up if we removed the setting of the control word in
> the assembly hooks.  I'd suggest masking all exceptions there, and
> then going through every entry point into a restored band (and the
> cold load) to make sure it sets up the floating-point environment
> appropriately.

There are two entry points?  There is the continuation created in
boot.c (deus ex machina!), and the one saved in a file by disk-save.
If that's it, I have two (new) lines for disk-save.

> diff --git a/src/runtime/savres.scm b/src/runtime/savres.scm
> @@ -54,2 +54,3 @@ USA.
>   (lambda (continuation)
> +    (let ((float-env (flo:environment)))
>      ;; GC cannot be allowed before the fixed-objects-vector
> @@ -76,2 +77,3 @@ USA.
>      (read-microcode-tables!)
> +      (flo:set-environment! float-env)
>      (lambda ()

I shortened that somewhat, with -U1, -b and a scissors.  But a patch
like that plus the end of runtime/make.scm (as is!) look to have it
covered.  And the end of make.scm already notes that floating-point
"mistakes" may NOT trap before the flo:default-environment is
established there.

> Perhaps Scheme ought to expose the x86 denormalized exception (with a
> null implementation for all the other machines we support -- er, uh,
> yeah), but I'm pretty sure it shouldn't be trapped by default.

I could simply patch FP_CONTROL_WORD to leave DENORM masked
everywhere?

It would be more cool if floenv.scm set up the machine with a default
environment, via libc.  It would be more "portable" (modulo
portabilitatedness of fenv.h), no?

> There's also a flush-to-zero control bit that we might want to expose
> somehow.

Isn't that an MMX register?  Is LIAR (going to be) generating SSE
instructions?

_______________________________________________
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu....
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel