On 10-08-17 06:15 AM, Mike Capp wrote:
Hypothetical: you're writing for two target platforms. Platform A only has hardware support for f32. Platform B has hardware support for both f32 and f64, but f64 is significantly slower. The current wording of Ref.Type.Float requires that float resolve to f32 on A and to f64 on B. That is, it precisely requires that "FPU behavior slows down *and* changes behavior on a platform-by-platform basis".
Well, yeah. But that's not going to happen on *all x86 targets*! :)
You're right that my OP was blurry, and I'm absolutely not suggesting that anyone should implement f80 (though reserving it sounds eminently sensible).
Ok. I'll cook up a reserved-tokens table in the lexer shortly then.
But I think that the existence of fast f64 on x86 - the ability to have your cake and eat it - is concealing a lack of clarity in this section.
Indeed. The manual needs slightly sharper language. I'll pick one more-obvious wording for now, but it shouldn't be assumed to be set in stone. By the time it makes sense to refer to the manual as a "spec", we'll probably have had far more people weigh in on such matters.
If I'm on x86 and I know it and I want fast predictable SSE2 mode, I'll declare as f64.
Unless you want it to turn into f128 when you get ported to SSE9 or whatever :) Probably we'll wind up with a set of c9x-esque types-by-intention in a system module somewhere: target.fast_float, target.wide_float, etc.
If I declare something as float, it's precisely because I *want* to change behaviour on a platform-by-platform basis; I want the compiler to pick the "best" type available, and I'm accepting a loss of predictability as the price of that. The trouble is that, without a definition of "best", it's hard to know whether float will capture my intent or not.
Yeah. And I guess this is where I get into discussing personal preferences and making up reasons to justify them :) But it's not always clear. I'd note also the number of times I've seen a project switch from -O2 to -Os and back again. Speed/size tradeoffs are universal in programming. It may be that switching to f80 (and thus rounding sizes up to 128-bits-per-float, say) doubles memory use in your program because it's FP-heavy! Who can say?
How about "The Rust type float [...] is the fastest supported floating-point type. If several types are equally fast, it is the largest of those types [...]" - would that capture the rationale behind your taste?
I suppose. It's possibly difficult to pin down a wording that captures the emotional reaction I get to "default to x87". When arguing taste, personal history figures into it: I've fixed numerous bugs over the years of the form "somehow I'm stuck generating x87 when, of course, I want SSE2". Users almost always ask for SSE2 when it's present on the platform; I recall far fewer reports of anyone asking for x87, unless they were targeting pre-KNI / PentiumPro generation.
Sorry to have come off a bit harsh at first. Of course there's some rationale for both, it's just a matter of picking good defaults. Which -- owing to the likelihood of further manual-rewriting over the coming months-to-years -- probably doesn't matter much at this point. We'll pick a default that's clear (your wording above is fine) and wait for someone with more knowledge or opinions pick something better.
-Graydon _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
