> 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
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.
> + (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
> 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
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
Isn't that an MMX register? Is LIAR (going to be) generating SSE