Date: Sat, 18 Jun 2011 17:25:14 -0700
From: Matt Birkholz <matt@birk...>
> From: Taylor R Campbell <campbell@mumb...>
> Date: Thu, 16 Jun 2011 18:38:12 +0000
> 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.
(What happens if I save a band on one OS (say, NetBSD) and load it on
another (say, Windows), and libc on each operating system treats the
floating-point environment significantly differently? This *probably*
won't be a problem, but it might be worth thinking about, because
bands are supposed to be OS-independent by default.)
> 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?
I don't understand. Can you elaborate? We already use libc to
control the floating-point environment if we can, and only fall back
to machine-specific code if we can't.
> 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
It's in both x87 and SSE. LIAR does generate SSE instructions for