On Friday, 4 July 2014 at 17:05:16 UTC, Walter Bright wrote:
On 7/4/2014 3:38 AM, Don wrote:
What is "the longest type supported by the native hardware"? I
don't know what
that means, and I don't think it even makes sense.
Most of the time, it is quite clear.
For example, Sparc has 128-bit quads, but they only have
partial support.
Effectively. they are emulated. Why on earth would you want to
use an emulated
type on some machines, but not on others?
Emulation is not native support.
I think the only difference it makes is performance. But there is
not very much difference in performance between double-double,
and implementations using microcode. Eg PowerPC double-doubles
operations require fewer clock cycles than x87 operations on 286.
Perhaps the intention was "the largest precision you can get
for free, without
sacrificing speed" then that's not clearly defined. On x86-32,
that was indeed
80 bits. But on other systems it doesn't have an obvious
answer.
On x86-64 it's not that simple. Nor on PPC or Sparc.
Yes, there is some degree of subjectivity on some platforms. I
don't see a good reason for hamstringing the compiler dev with
legalese for Platform X with legalese that isn't quite the
right thing to do for X.
I agree. But I think we can achieve the same outcome while
providing more semantic guarantees to the programmer.
I think the intention of the spec is clear, and the compiler
implementor can be relied on to exercise good judgement.
The problem is that the developer cannot write code without
knowing the semantics.
For example, one of the original motivations for having 80-bit
floats on the x87 was that for many functions, they give you
correctly-rounded results for 'double' precision. If you don't
have 80-bit reals, then you need to use far more complicated
algorithms.
If your code needs to work on a system with only 64 bit reals,
then you have to do the hard work.
Something I've come to realize, was that William Kahan's work was
done in a world before generic programming. He had constraints
that we don't have.
Our metaprogramming system gives us great tools to get the
highest accuracy and performance out of any processor. We can
easily cope with the messy reality of real-world systems, we
don't need to follow Java in pretending they are all the same.
This is something we're good at!
A 'real' type that has system-dependent semantics is a poor-man's
generics.
Take a look at std.math, and see all the instances of 'static if
(real.mant_dig == '. Pretty clearly, 'real' is acting as if it
were a template parameter.
And my experience is that any code which doesn't treat 'real' as
a template parameter, is probably incorrect. I think we should
acknowledge this.
