On 16/08/2010 7:13 PM, Jeff Schultz wrote:
Would anything else in the spec break if float was not guaranteed to
be one of f32 or f64?
It wouldn't be nice if 'float' could sometimes be a type that couldn't
be explicitly and portably mandated, so perhaps the solution is to
reserve f80, f96, f128, and so on. Even so, 'float' would probably
still be f64 on any machine with a 64 bit fp unit regardless of
availability of something like f80. It might take a while to add
software implementations of the bigger types, but reserving the
keywords now looks the right step.
Reserving is harmless, sure. At very least lets people carve out
non-portable dialects, avoid collisions.
I'm familiar with Kahan's arguments regarding FP, and I'm in no way
intending to go down the road of mandating "all FP runs in
strict/minimal/java 100%-reproducible mode" or anything like that.
There's a point beyond which you just have to let the
hardware/OS/platform do the best it can, and/or let the programmer
control matters if they know what they're doing.
That said, I think the initial query here is a bit blurry. Aside from
the wording in the manual (which, sure, is a bit off as it implies x87
doesn't have an 80-bit mode, I'll fix that), there are three separable
concepts / issues here:
(1) 80-bit FP temporaries used within the FPU
(2) an 'f80' type that is defined to be 80 bits
(3) whether, if you have f80, float expands to f80 on x86
Concept (1) occurs ... quite often in C code that just uses 64-bit
doubles. It's a mode the x87 is often set to. It strictly increases
precision of calculation, while still spitting out 64-bit values when
they're written back to (say) memory or 64-bit GPRs or whatever. This is
fine. I'm not going to try to prohibit user code from turning on this
mode when they happen to doing x87 codegen. That's assuming anyone
bothers wiring up LLVM's x87-codegen and making it a
thing-you-can-turn-on in rustc. Personally I'm unlikely to bother, I'll
just set it to SSE2 mode and be done with it. Modern codes *usually*
switch to SSE2 / 64-bit-only anyway, for speed, but whatever floats your
boat. Patches welcome. You want slower and more-accurate, implement and
turn on x87 codegen, and set that bit. Likewise the various rounding
modes or whatever. It's done by an FLDCW we can't really stop you from
issuing in some native call to C anyways.
Note though that (1) is strictly a backend / codegen / library issue.
The user types involved are still all f64.
Concept (2) is where we get into a putative f80 type. Like, a variable
type, not just a temporary type. It's certainly possible to implement
(once reserved). However, this concept is nowhere near as prevalent or
(I think) important as the first email is implying. You can get at it --
sometimes! -- by writing 'long double' in C. Sometimes this might get
you 80 bits. Depending. On some platforms it'll turn into a synonym for
'double' (say, MSVC), on some platforms it'll go to 128 bit. On some
chips it turns into a weird-o non-IEEE FP format. Do a google code
search for it thought. It's like ... a few math libs and a bunch of
compatibility headers that people keep blindly copying around. It's rare.
Since I'm not interested in supporting x87 codegen with my own sweat,
you can guess where my feelings about all the even-more-rare feature
goes :) Same bucket as the saturating-arithmetic modes in MMX and vector
bundles and all these sorts of things. Patches welcome so long as the
feature's clearly a platform extension and doesn't confuse programs that
aren't asking for it.
Concept (3) is, well ... a bit of a matter of taste. But I think
probably an easy to explain one. Follow the supposed logic of doing (3):
you're on x86. So it has an x87. So float turns into f80. So now your
FPU behavior ... slows down *and* changes behavior on a
platform-by-platform basis. Accuracy is nice, but you want the default
to be "pick accuracy over speed and predictability"? I think this would
be undesirable. Most CPUs -- hell, even GPUs -- optimize for f64 these
days, and most support it. I want float to default to try to hit that
case (until f128 is as prevalent as f64, some magical day...)
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
