RE: Internal representation of double variables - 3.4.6 vs 4.1.0

["John \(Eljay\) Love-Jensen" <eljay@adobe.com>]

Hi Terry,

> Is there any sensible reason that these options seem to buried in processor-specific sections?

My guess is because they are processor-specific options.

> Surely the hardware floating point model varies on more than just the x86 family and friends.

Yes.  For example, not all 680x0 machines has a FPU.

> Why isn't there a simple, global option to get a portable floating point model?

Because there are different FPU facilities on different platforms that may have a different, non-portable floating-point model.

> Particularly now that gfortran is becoming more popular!

If the Fortran users express a desire for some Fortran level floating-point compliance to a portable floating-point model, perhaps the maintainer of the gfortran front-end tool-chain driver will add a flag to that effect.

I imagine such a flag would have these guarantees:
+ behind the scenes, specifies the processor-specific option to insure floating-point portability
+ may impose severe performance penalties (one-to-two orders of magnitude) on some platforms
+ may cause the compile to fail if the floating-point constraint cannot be fulfilled (which is probably a good thing)

> Tying the floating point model to a particular hardware feature/instruction set (SSE) seems absolutely absurd to me.  It should be abstracted to a much higher level.

It's a trade-off, without a doubt.

Java has a facility that allows strong guarantees on floating-point fidelity.  And Mathematica allows very powerful expression of symbolic and mathematical manipulation and expression.  And there's always Lisp.

Sincerely,
--Eljay