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
   > 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.

Looks reasonable.

(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
   everywhere?

Sounds right.

   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
   > somehow.

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

It's in both x87 and SSE.  LIAR does generate SSE instructions for
amd64.

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