Ben Hinkle wrote:

> What happens when someone declares a variable as quadruple on a platform without hardware support? Does D plug in a software quadruple implementation? That isn't the right thing to do. That's been my whole point of bringing up Java's experience. They tried to foist too much rigor on their floating point model in the name of portability and had to redo it. 

Choke... Splutter... Die.

Java did not re-implement extended in software. They just ignored it...

--anders

I wrote, in response to Ben Hinkle:

>> What happens when someone declares a variable as quadruple on a platform without hardware support? 
>
> Choke... Splutter... Die.

Just to be perfectly clear:
Those are the sounds the *compiler* would make, not Ben :-)

Seriously, trying to use the extended or quadruple types on
platforms where they are not implemented in hardware would
be a compile time error. "real" would silently fall back.

--anders

"Anders F Björklund" <afb@algonet.se> wrote in message news:d2rcfd$1ueq$2@digitaldaemon.com...
>I wrote, in response to Ben Hinkle:
>
>>> What happens when someone declares a variable as quadruple on a platform without hardware support?
>>
>> Choke... Splutter... Die.
>
> Just to be perfectly clear:
> Those are the sounds the *compiler* would make, not Ben :-)

yup, I read it that way - though I did notice I spluttered a bit this morning...

> Seriously, trying to use the extended or quadruple types on platforms where they are not implemented in hardware would be a compile time error. "real" would silently fall back.

OK, needless to say I think a builtin type that is illegal on many platforms is a mistake.

Ben Hinkle wrote:

> OK, needless to say I think a builtin type that
> is illegal on many platforms is a mistake. 

That is actually *not* needless to say,
but Walter agrees with you on the topic.

Just as we can talk about "real" as the
64/80/96/128 bit floating point type,
and not somehow assume that it will be
80 bits - then I'm perfectly fine with it.

"long double" in C/C++ works just the same.

But if you *do* want to talk about the "X87"
80-bit type, then please do by all means use
"extended" instead. Less confusion, all around ?
(let's save "quadruple" for later, with "cent")

--anders

"Anders F Björklund" <afb@algonet.se> wrote in message news:d2rdjp$1vfl$1@digitaldaemon.com...
> Ben Hinkle wrote:
>
>> OK, needless to say I think a builtin type that
>> is illegal on many platforms is a mistake.
>
> That is actually *not* needless to say,
> but Walter agrees with you on the topic.
>
> Just as we can talk about "real" as the
> 64/80/96/128 bit floating point type,
> and not somehow assume that it will be
> 80 bits - then I'm perfectly fine with it.
>
> "long double" in C/C++ works just the same.
>
> But if you *do* want to talk about the "X87"
> 80-bit type, then please do by all means use
> "extended" instead. Less confusion, all around ?
> (let's save "quadruple" for later, with "cent")
>
> --anders


The IEEE 754r suggests that there won't be
a 80bit nor a 96bit format in future (whenever
this may be).

Ref.: My today's post about IEEE 754r

Bob W wrote:

>>But if you *do* want to talk about the "X87"
>>80-bit type, then please do by all means use
>>"extended" instead. Less confusion, all around ?
>>(let's save "quadruple" for later, with "cent")
> 
> The IEEE 754r suggests that there won't be
> a 80bit nor a 96bit format in future (whenever
> this may be).

According to Sun, Microsoft, IBM and Apple
there isn't such a 80-bit type today even... ;-)

BTW; the 96-bit floating point was the type
preferred by the 68K families FPU processor

--anders

"Anders F Björklund" <afb@algonet.se> wrote in message news:d2qq5u$1aau$1@digitaldaemon.com...
> Walter wrote:
> >>If so, just tell me it's better to have a flexible width language type, than to have some types be unavailable on certain FPU computer hardware?
> > Yes, I believe that is better. Every once in a while, an app *does*
care,
> > but they're screwed anyway if the hardware won't support it.
> I just fail to see how real -> double/extended, is any different from the int -> short/long that C has gotten so much beating for already ?

Philosophically, they are the same. Practically, however, they are very different. Increasing integer sizes gives more range, and integer calculations tend to be *right* or *wrong*. Floating point increased size, however, gives more precision. So an answer is *better* or *worse*, insted of right or wrong. (Increased bits also gives fp more range, but if the range is not enough, it fails cleanly with an overflow indication, not just wrapping around and giving garbage.) In other words, decreasing the bits in an fp value tends to gracefully degrade the results, which is very different from the effect on integer values.


> The suggestion was to have fixed precision types:
> - float => IEEE 754 Single precision (32-bit)
> - double => IEEE 754 Double precision (64-bit)
> - extended => IEEE 754 Double Extended precision (80-bit)
> - quadruple => "IEEE 754" Quadruple precision (128-bit)
>
> And then have "real" be an alias to the largest hardware-supported type. It wouldn't break code more than if it was a variadic size type format ?

I just don't see the advantage. If you use "extended" and your hardware doesn't support it, you're out of luck. If you use "real", your program will still compile and run. If certain characteristics of the "real" type are required, one can use static asserts on the properties of real.


> >>It was my understanding that it was aligned to 96 bits on X86,
> > That's not a power of 2, so won't work as alignment.
> You lost me ? (anyway, I suggested 128 - which *is* a power of two)

There is nothing set up in the operating system or linker to handle alignment to 96 bits or other values not a power of 2. Note that there is a big difference between the size of an object and what its alignment is.

> But it was my understanding that on the X86/X86_64 family of processors
> that Windows used to use 10-byte doubles (and then removed extended?),
> and that Linux i386(-i686) uses 12-byte doubles and Linux X86_64 now
> uses 16-byte doubles (using the GCC option of -m128bit-long-double)
>
> And that was *not* a suggestion, but how it actually worked... Now ?

Windows uses 10 byte doubles aligned on 2 byte boundaries. I'm not sure if gcc on linux does it that way or not.

Walter wrote:

> Philosophically, they are the same. Practically, however, they are very
> different. Increasing integer sizes gives more range, and integer
> calculations tend to be *right* or *wrong*. Floating point increased size,
> however, gives more precision. So an answer is *better* or *worse*, insted
> of right or wrong. (Increased bits also gives fp more range, but if the
> range is not enough, it fails cleanly with an overflow indication, not just
> wrapping around and giving garbage.) In other words, decreasing the bits in
> an fp value tends to gracefully degrade the results, which is very different
> from the effect on integer values.

Interesting view of it, but I think that int fixed-point math degrades gracefully in the same way (using integers) Still with wrapping, though.

Not that I've used fixed-point in quite some time, and it doesn't
seem like I will be either - with the current CPUs and the new APIs.

> I just don't see the advantage. If you use "extended" and your hardware
> doesn't support it, you're out of luck. If you use "real", your program will
> still compile and run. If certain characteristics of the "real" type are
> required, one can use static asserts on the properties of real.

To be honest, I was just tired of the "real is 80 bits" all over D ?
And more than a little annoyed at the ireal and creal, of course ;-)

I always thought that "long double" was confusing, so now I've started
to use "extended" for 80-bit and "real" for the biggest-available-type.

And it's working out good so far.

>>And that was *not* a suggestion, but how it actually worked... Now ?
> 
> Windows uses 10 byte doubles aligned on 2 byte boundaries. I'm not sure if
> gcc on linux does it that way or not.

Linux on X86 aligns to 12 bytes, and Linux on X86_64 aligns to 16 bytes.

--anders

>> Windows uses 10 byte doubles aligned on 2 byte boundaries. I'm not sure if gcc on linux does it that way or not.
> 
> Linux on X86 aligns to 12 bytes, and Linux on X86_64 aligns to 16 bytes.

Make that "Linux on X86 aligns to 4 bytes, by making the size 12".

You know what I mean :-)

--anders

"Anders F Björklund" <afb@algonet.se> wrote in message news:d2rhtd$258a$1@digitaldaemon.com...
> Bob W wrote:
> > The IEEE 754r suggests that there won't be
> > a 80bit nor a 96bit format in future (whenever
> > this may be).
> According to Sun, Microsoft, IBM and Apple
> there isn't such a 80-bit type today even... ;-)

I fear it will be constant struggle to keep the chipmakers from dropping it and the OS vendors from abandoning support.