mit-scheme-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MIT-Scheme-devel] Ubuntu 11.04 and FE_DFL_ENV.


From: Taylor R Campbell
Subject: Re: [MIT-Scheme-devel] Ubuntu 11.04 and FE_DFL_ENV.
Date: Sun, 19 Jun 2011 02:13:56 +0000
User-agent: IMAIL/1.21; Edwin/3.116; MIT-Scheme/9.1

   Date: Sat, 18 Jun 2011 17:25:14 -0700
   From: Matt Birkholz <address@hidden>

   > From: Taylor R Campbell <address@hidden>
   > 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]