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

[Matt Birkholz]

> From: Taylor R Campbell <address@hidden>
> Date: Thu, 16 Jun 2011 18:38:12 +0000
> 
>    Date: Thu, 16 Jun 2011 10:11:28 -0700
>    From: Matt Birkholz <address@hidden>
> 
>    [...]  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?