> From: Taylor R Campbell <[email protected]> > Date: Thu, 16 Jun 2011 18:38:12 +0000 > > Date: Thu, 16 Jun 2011 10:11:28 -0700 > From: Matt Birkholz <[email protected]> > > [...] 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 [email protected] https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
