Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #65533 > unrolled thread

Handling numeric types in interpreter

Back to article view | Back to comp.lang.c

Contents

  Handling numeric types in interpreter luser droog <luser.droog@gmail.com> - 2015-07-13 19:33 -0700
    Re: Handling numeric types in interpreter jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-14 07:31 +0200
    Handling numeric types in interpreter asetofsymbols@gmail.com - 2015-07-14 00:35 -0700
    Re: Handling numeric types in interpreter David Kleinecke <dkleinecke@gmail.com> - 2015-07-14 08:55 -0700
    Re: Handling numeric types in interpreter Bartc <bc@freeuk.com> - 2015-07-15 23:18 +0100
      Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-24 00:21 -0700
        Re: Handling numeric types in interpreter Keith Thompson <kst-u@mib.org> - 2015-07-24 08:36 -0700
          Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-24 11:04 -0700
            Re: Handling numeric types in interpreter Keith Thompson <kst-u@mib.org> - 2015-07-24 12:25 -0700
              Re: Handling numeric types in interpreter James Kuyper <jameskuyper@verizon.net> - 2015-07-24 22:21 -0400
                Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 02:28 -0700
                  Re: Handling numeric types in interpreter Bartc <bc@freeuk.com> - 2015-07-25 15:16 +0100
                  Re: Handling numeric types in interpreter Richard Damon <Richard@Damon-Family.org> - 2015-07-25 11:03 -0400
                  Re: Handling numeric types in interpreter Keith Thompson <kst-u@mib.org> - 2015-07-25 10:05 -0700
                Re: Handling numeric types in interpreter gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-25 12:32 +0000
                  Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 06:12 -0700
                    Re: Handling numeric types in interpreter Keith Thompson <kst-u@mib.org> - 2015-07-25 10:08 -0700
                      Re: Handling numeric types in interpreter ais523 <ais523@nethack4.org> - 2015-07-28 17:50 +0000
                        Re: Handling numeric types in interpreter Keith Thompson <kst-u@mib.org> - 2015-07-28 11:52 -0700
                        Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-28 12:25 -0700
                        Re: Handling numeric types in interpreter Richard Heathfield <rjh@cpax.org.uk> - 2015-07-28 20:52 +0100
                          Re: Handling numeric types in interpreter jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-28 23:01 +0200
                            Re: Handling numeric types in interpreter Keith Thompson <kst-u@mib.org> - 2015-07-28 14:44 -0700
                              Re: Handling numeric types in interpreter Ian Collins <ian-news@hotmail.com> - 2015-07-29 09:43 +1200
                              Re: Handling numeric types in interpreter glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-28 23:10 +0000
                                Re: Handling numeric types in interpreter Ian Collins <ian-news@hotmail.com> - 2015-07-29 12:04 +1200
                                  Re: Handling numeric types in interpreter Melzzzzz <mel@zzzzz.com> - 2015-07-29 02:39 +0200
                                Re: Handling numeric types in interpreter jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-29 12:04 +0200
                                  Re: Handling numeric types in interpreter glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-29 14:58 +0000
                                Re: Handling numeric types in interpreter jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-29 14:14 +0200
                                  Re: Handling numeric types in interpreter Bartc <bc@freeuk.com> - 2015-07-29 13:29 +0100
                                    Re: Handling numeric types in interpreter Keith Thompson <kst-u@mib.org> - 2015-07-29 08:48 -0700
                                  Re: Handling numeric types in interpreter Keith Thompson <kst-u@mib.org> - 2015-07-29 08:45 -0700
                              Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-28 16:28 -0700
                              Re: Handling numeric types in interpreter jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-29 12:02 +0200
                              Re: Handling numeric types in interpreter Keith Thompson <kst-u@mib.org> - 2015-07-29 08:51 -0700
                                Re: Handling numeric types in interpreter jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-29 18:35 +0200
                                  Re: Handling numeric types in interpreter Keith Thompson <kst-u@mib.org> - 2015-07-29 10:47 -0700
                    Re: Handling numeric types in interpreter Robert Wessel <robertwessel2@yahoo.com> - 2015-07-25 15:46 -0500
                      Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 14:08 -0700
                        Re: Handling numeric types in interpreter Keith Thompson <kst-u@mib.org> - 2015-07-25 15:42 -0700
                          Re: Handling numeric types in interpreter Robert Wessel <robertwessel2@yahoo.com> - 2015-07-26 00:31 -0500
                      Re: Handling numeric types in interpreter James Kuyper <jameskuyper@verizon.net> - 2015-07-25 17:48 -0400
                        Re: Handling numeric types in interpreter Robert Wessel <robertwessel2@yahoo.com> - 2015-07-25 17:31 -0500
                          Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 15:57 -0700
                            Re: Handling numeric types in interpreter Bartc <bc@freeuk.com> - 2015-07-26 01:07 +0100
                              Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 17:26 -0700
                                Re: Handling numeric types in interpreter Richard Damon <Richard@Damon-Family.org> - 2015-07-25 22:25 -0400
                          Re: Handling numeric types in interpreter James Kuyper <jameskuyper@verizon.net> - 2015-07-25 19:04 -0400
                            Re: Handling numeric types in interpreter Robert Wessel <robertwessel2@yahoo.com> - 2015-07-26 00:23 -0500
                              Re: Handling numeric types in interpreter James Kuyper <jameskuyper@verizon.net> - 2015-07-26 08:24 -0400
                                Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-26 06:36 -0700
                                  Re: Handling numeric types in interpreter Robert Wessel <robertwessel2@yahoo.com> - 2015-07-26 16:30 -0500
                                  Re: Handling numeric types in interpreter Keith Thompson <kst-u@mib.org> - 2015-07-26 15:42 -0700
                                Re: Handling numeric types in interpreter Robert Wessel <robertwessel2@yahoo.com> - 2015-07-26 16:28 -0500
                                  Re: Handling numeric types in interpreter James Kuyper <jameskuyper@verizon.net> - 2015-07-26 18:57 -0400
                                    Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-26 16:20 -0700
                        Re: Handling numeric types in interpreter Keith Thompson <kst-u@mib.org> - 2015-07-25 15:58 -0700
                Re: Handling numeric types in interpreter James Kuyper <jameskuyper@verizon.net> - 2015-07-25 12:56 -0400
                  Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 14:18 -0700
        Re: Handling numeric types in interpreter glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-24 18:06 +0000
          Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-24 11:16 -0700
            Re: Handling numeric types in interpreter glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-24 23:06 +0000
              Re: Handling numeric types in interpreter Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-24 16:21 -0700
    Re: Handling numeric types in interpreter Michael Angelo Ravera <maravera@prodigy.net> - 2015-07-15 19:13 -0700
      Re: Handling numeric types in interpreter luser droog <luser.droog@gmail.com> - 2015-07-23 08:36 -0700

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#66506

On 28/07/15 18:50, ais523 wrote:
> Keith Thompson wrote:
>> I have no problem with you conclusion (that double is good enough for
>> your purposes).  I disagree with your rationale (that long double is
>> potentially non-portable).
>
> long double is actually one of the least portable C89 features.

In a sense, it is one of the /most/ portable features! The Standard 
doesn't require it to do anything that double doesn't do, and therefore 
any implementation can implement it for free by interpreting it as a 
synonym for double. (And some do.) People who have to write portable 
code know this, so they don't bother using it, making it 100% portable 
and 100% useless.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#66507

Le 28/07/2015 21:52, Richard Heathfield a écrit :
> On 28/07/15 18:50, ais523 wrote:
>> Keith Thompson wrote:
>>> I have no problem with you conclusion (that double is good enough for
>>> your purposes).  I disagree with your rationale (that long double is
>>> potentially non-portable).
>>
>> long double is actually one of the least portable C89 features.
>
> In a sense, it is one of the /most/ portable features! The Standard
> doesn't require it to do anything that double doesn't do, and therefore
> any implementation can implement it for free by interpreting it as a
> synonym for double. (And some do.) People who have to write portable
> code know this, so they don't bother using it, making it 100% portable
> and 100% useless.
>

I disagree.

lcc-win has two implementations of long double: the "standard" intel 80 
bits long double in hardware (FPU) and a software implementation of 128 
bit long doubles (called float128_t)

Those types allow you to go

1) Beyond the range of double (1.79769e+308)

2) Beyond the accuracy of double. The 80 bits long double provides for 
19 digits, and the 128 bits long double provides for 34 decimal digits 
precision)

This is needed in calculations where the intermediate results can go 
beyond the range/precision offered by doubles.

For people that do not do numerical work long double is useless. OK.

But for other people long double is a necessity.

[toc] | [prev] | [next] | [standalone]

#66508

jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 28/07/2015 21:52, Richard Heathfield a écrit :
>> On 28/07/15 18:50, ais523 wrote:
>>> Keith Thompson wrote:
>>>> I have no problem with you conclusion (that double is good enough for
>>>> your purposes).  I disagree with your rationale (that long double is
>>>> potentially non-portable).
>>>
>>> long double is actually one of the least portable C89 features.
>>
>> In a sense, it is one of the /most/ portable features! The Standard
>> doesn't require it to do anything that double doesn't do, and therefore
>> any implementation can implement it for free by interpreting it as a
>> synonym for double. (And some do.) People who have to write portable
>> code know this, so they don't bother using it, making it 100% portable
>> and 100% useless.
>
> I disagree.
>
> lcc-win has two implementations of long double: the "standard" intel 80 
> bits long double in hardware (FPU) and a software implementation of 128 
> bit long doubles (called float128_t)
[...]
> For people that do not do numerical work long double is useless. OK.
>
> But for other people long double is a necessity.

I disagree with both of you.

For portable code you can't assume that long double is bigger than
double -- but you can assume that it's at least as big.  If you
want to use the biggest floating-point type available, that's
long double.  On some platforms you won't get any more precision
or range than double; on others, you will.  If the extra range and
precision on *some* systems is worth the inconsistency then you win.
(double isn't guaranteed to have the same range and precision across
systems, but these days it's *usually* 64-bit IEEE.)

Also, since long double is guaranteed to be the largest
floating-point type (excluding extensions), it can be handy if
client code might be giving you values of any floating-point type.

On the other hand, if "long double is a necessity" (by which I
presume you mean that range and/or precision greater than that of
double is a necessity), then you're out of luck if you're using a
system where double and long double have the same representation.
Using a different compiler that has a larger long double type is
great if you have that option.  Not everyone does.

BTW, I'm curious about your two different implementations of long
double, 80 and 128 bits.  How do you specify which one you want
to use?  If it's a compile-time option, does the linker prevent
you from linking object files that don't use the same representation?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#66509

Keith Thompson wrote:
> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>
>> lcc-win has two implementations of long double: the "standard" intel 80
>> bits long double in hardware (FPU) and a software implementation of 128
>> bit long doubles (called float128_t)
> [...]
>
> BTW, I'm curious about your two different implementations of long
> double, 80 and 128 bits.  How do you specify which one you want
> to use?  If it's a compile-time option, does the linker prevent
> you from linking object files that don't use the same representation?

"and a software implementation of 128bit long doubles (called float128_t)"

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#66511

Keith Thompson <kst-u@mib.org> wrote:
> jacobnavia <jacob@jacob.remcomp.fr> writes:
(big snip)
>> For people that do not do numerical work long double is useless. OK.

>> But for other people long double is a necessity.
 
> I disagree with both of you.
 
> For portable code you can't assume that long double is bigger than
> double -- but you can assume that it's at least as big.  If you
> want to use the biggest floating-point type available, that's
> long double.  On some platforms you won't get any more precision
> or range than double; on others, you will.  If the extra range and
> precision on *some* systems is worth the inconsistency then you win.
> (double isn't guaranteed to have the same range and precision across
> systems, but these days it's *usually* 64-bit IEEE.)

The idea behind the 80 bit temporary real (intel's name) format
is that it holds more precision and range for intermediate
calculations.  The registers are that size, and intermediate
results are stored in the registers.  On the other hand, you
can't guarantee that the compiler will figure it out. 
 
> Also, since long double is guaranteed to be the largest
> floating-point type (excluding extensions), it can be handy if
> client code might be giving you values of any floating-point type.
 
> On the other hand, if "long double is a necessity" (by which I
> presume you mean that range and/or precision greater than that of
> double is a necessity), then you're out of luck if you're using a
> system where double and long double have the same representation.
> Using a different compiler that has a larger long double type is
> great if you have that option.  Not everyone does.

In addition, there are surprising results when the compiler does
keep intermediate values in registers. As there are a limited 
number, it might not keep all intermediate values in registers,
so you get different values for the same expression. 

Also, optimization might keep values in registers between
statements, again surprising the user.
 
> BTW, I'm curious about your two different implementations of long
> double, 80 and 128 bits.  How do you specify which one you want
> to use?  If it's a compile-time option, does the linker prevent
> you from linking object files that don't use the same representation?

There is still a shortage of hardware implementations of 128 bit
formats. Maybe when the new IEEE decimal formats get more popular.
The 64 bit is supposed to be single precision, and the 128 bit
double precision.  It will be interesting to see compiler 
support for these formats.

-- glen

[toc] | [prev] | [next] | [standalone]

#66513

glen herrmannsfeldt wrote:

> There is still a shortage of hardware implementations of 128 bit
> formats. Maybe when the new IEEE decimal formats get more popular.
> The 64 bit is supposed to be single precision, and the 128 bit
> double precision.  It will be interesting to see compiler
> support for these formats.

The only implementation of IEEE 754-2008 128 bit floating point values 
I'm aware of is Oracle's compiler on SPARC:

https://docs.oracle.com/cd/E37069_01/html/E39019/z4000ac019358.html#scrolltoc

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#66514

On Wed, 29 Jul 2015 12:04:32 +1200
Ian Collins <ian-news@hotmail.com> wrote:

> glen herrmannsfeldt wrote:
> 
> > There is still a shortage of hardware implementations of 128 bit
> > formats. Maybe when the new IEEE decimal formats get more popular.
> > The 64 bit is supposed to be single precision, and the 128 bit
> > double precision.  It will be interesting to see compiler
> > support for these formats.
> 
> The only implementation of IEEE 754-2008 128 bit floating point
> values I'm aware of is Oracle's compiler on SPARC:
> 
> https://docs.oracle.com/cd/E37069_01/html/E39019/z4000ac019358.html#scrolltoc
> 

https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format

[toc] | [prev] | [next] | [standalone]

#66522

Le 29/07/2015 01:10, glen herrmannsfeldt a écrit :
> In addition, there are surprising results when the compiler does
> keep intermediate values in registers. As there are a limited
> number, it might not keep all intermediate values in registers,
> so you get different values for the same expression.
>
> Also, optimization might keep values in registers between
> statements, again surprising the user.

lcc-win avoids all those troubles by maintaining long doubles in the FPU 
registers, and doubles in the SSE registers. That way, there are no 
surprises.

[toc] | [prev] | [next] | [standalone]

#66526

jacobnavia <jacob@jacob.remcomp.fr> wrote:

(snip, I wrote, regarding x87 floating point)
>> In addition, there are surprising results when the compiler does
>> keep intermediate values in registers. As there are a limited
>> number, it might not keep all intermediate values in registers,
>> so you get different values for the same expression.

>> Also, optimization might keep values in registers between
>> statements, again surprising the user.
 
> lcc-win avoids all those troubles by maintaining long doubles in the FPU 
> registers, and doubles in the SSE registers. That way, there are no 
> surprises.

The original idea for the 8087 was a virtual stack. That it would
interrupt when the stack got full, the interrupt routine would 
write some registers to memory somewhere, and continue on. 
On stack underflow, they would be restored, and programs could
run independent of the actual (8 element) stack. 

But no-one tried to write the interrupt routine until the 8087
was done, and it turned out not to be possible. I don't reemmber
the exact details, but they are related to restoring some of 
the state bits. You can load and store registers, but not some
other bits that are needed.

-- glen

[toc] | [prev] | [next] | [standalone]

#66523

Le 29/07/2015 01:10, glen herrmannsfeldt a écrit :
> In addition, there are surprising results when the compiler does
> keep intermediate values in registers. As there are a limited
> number, it might not keep all intermediate values in registers,
> so you get different values for the same expression.
>
> Also, optimization might keep values in registers between
> statements, again surprising the user.

This can be completely avoided if you use (in Intel processors) two 
different register sets to hold long doubles (in the FPU) and doubles 
(in the SSE registers).

I did this two years ago. Gcc also does it, as far as I know. The only 
big compiler system that doesn't have long double implemented is 
Microsoft Visual Studio.

[toc] | [prev] | [next] | [standalone]

#66524

On 29/07/2015 13:14, jacobnavia wrote:
> Le 29/07/2015 01:10, glen herrmannsfeldt a écrit :
>> In addition, there are surprising results when the compiler does
>> keep intermediate values in registers. As there are a limited
>> number, it might not keep all intermediate values in registers,
>> so you get different values for the same expression.
>>
>> Also, optimization might keep values in registers between
>> statements, again surprising the user.
>
> This can be completely avoided if you use (in Intel processors) two
> different register sets to hold long doubles (in the FPU) and doubles
> (in the SSE registers).

In this example:

     double x,y;
     ... (x/y) ...

The term x/y might have extra precision that can't be represented in 64 
bits. Are you saying you will do this calculation using the FPU 
registers, or does that only happen when 'long double' is specified?

(The problem glen mentioned is when calculations on doubles are done in 
the FPU registers. The intermediate value of 80 bits is reduced to 64 
bits if written out to memory, but stays at 80 if optimisation keeps it 
in the registers. While when using XMM registers, the intermediate value 
is only 64 bits anyway.)

> I did this two years ago. Gcc also does it, as far as I know. The only
> big compiler system that doesn't have long double implemented is
> Microsoft Visual Studio.

long double doesn't work properly in gcc/mingw under Windows. Probably 
to do with using MSVCRT's version of printf, so that %Lf is not 
supported. So maybe it's getting the right answer, but it's not possible 
to see it!

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#66528

Bartc <bc@freeuk.com> writes:
[...]
> long double doesn't work properly in gcc/mingw under Windows. Probably 
> to do with using MSVCRT's version of printf, so that %Lf is not 
> supported. So maybe it's getting the right answer, but it's not possible 
> to see it!

As I mentioned elsethread, you can work around this problem by compiling
with
    gcc -D__USE_MINGW_ANSI_STDIO=1
or by using
    #define __USE_MINGW_ANSI_STDIO 1
at the top of your source file.

Or you can convert to double before printing (which doesn't help if you
need to print a value that's outside the range of double).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#66527

jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 29/07/2015 01:10, glen herrmannsfeldt a écrit :
>> In addition, there are surprising results when the compiler does
>> keep intermediate values in registers. As there are a limited
>> number, it might not keep all intermediate values in registers,
>> so you get different values for the same expression.
>>
>> Also, optimization might keep values in registers between
>> statements, again surprising the user.
>
> This can be completely avoided if you use (in Intel processors) two 
> different register sets to hold long doubles (in the FPU) and doubles 
> (in the SSE registers).
>
> I did this two years ago. Gcc also does it, as far as I know. The only 
> big compiler system that doesn't have long double implemented is 
> Microsoft Visual Studio.

If I'm not mistaken, MSVS *does* implement long double in a manner
that conforms to the C standard.  It just happens to have the same
representation as double.  (I'm not defending MS's decision to do
it this way just pointing out that it's conforming.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#66512

On Tuesday, July 28, 2015 at 10:35:27 PM UTC+1, Keith Thompson wrote:
> jacobnavia <jacob@jacob.remcomp.fr> writes:
>
> For portable code you can't assume that long double is bigger than
> double -- but you can assume that it's at least as big.  If you
> want to use the biggest floating-point type available, that's
> long double.  On some platforms you won't get any more precision
> or range than double; on others, you will.  If the extra range and
> precision on *some* systems is worth the inconsistency then you win.
> (double isn't guaranteed to have the same range and precision across
> systems, but these days it's *usually* 64-bit IEEE.)
> 
If you've got to worry about the extra bits of precision that a
long double gives you, the usually you need to know exactly what
is the accuracy of the floating point system you are using. 
Otherwise you get nasty intermittent bugs as mathematical 
calculations fail to converge, or consistency is violated
(if p is to the left of line AB and q is also to the left, then
the line pq should not intersect AB, not always true when you get 
down to the last few bits with typical geometry routines).
 

[toc] | [prev] | [next] | [standalone]

#66521

Le 28/07/2015 23:44, Keith Thompson a écrit :
> you're out of luck if you're using a
> system where double and long double have the same representation.

Exactly. Avoid those compilers, and if you can't avoid them you are stuck.

[toc] | [prev] | [next] | [standalone]

#66529

Keith Thompson <kst-u@mib.org> writes:
> jacobnavia <jacob@jacob.remcomp.fr> writes:
[...]
>> lcc-win has two implementations of long double: the "standard" intel 80 
>> bits long double in hardware (FPU) and a software implementation of 128 
>> bit long doubles (called float128_t)
[...]
> BTW, I'm curious about your two different implementations of long
> double, 80 and 128 bits.  How do you specify which one you want
> to use?  If it's a compile-time option, does the linker prevent
> you from linking object files that don't use the same representation?

You posted a followup to the above post, but you didn't answer the
quoted question.

Can lcc-win treat your float128_t type as "long double", or is
float128_t always a distinct type?  If the size of long double is
configurable, how do you avoid mixing code using 80-bit long double
with code using 128-bit long double?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#66534

Le 29/07/2015 17:51, Keith Thompson a écrit :
> Keith Thompson <kst-u@mib.org> writes:
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
> [...]
>>> lcc-win has two implementations of long double: the "standard" intel 80
>>> bits long double in hardware (FPU) and a software implementation of 128
>>> bit long doubles (called float128_t)
> [...]
>> BTW, I'm curious about your two different implementations of long
>> double, 80 and 128 bits.  How do you specify which one you want
>> to use?  If it's a compile-time option, does the linker prevent
>> you from linking object files that don't use the same representation?
>
> You posted a followup to the above post, but you didn't answer the
> quoted question.
>
> Can lcc-win treat your float128_t type as "long double", or is
> float128_t always a distinct type?  If the size of long double is
> configurable, how do you avoid mixing code using 80-bit long double
> with code using 128-bit long double?
>

Read the message I posted:

lcc-win has two implementations of long double: the "standard" intel 80
bits long double in hardware (FPU) and a software implementation of 128
bit long doubles (called float128_t)

long double is always Intel's 80 bits FPU representation
float128_t is a distinct type that *could* be used as long double but 
this is NOT done by the compiler since the software implementation is 
100 times slower than the hardware one...

So: long double is always 80 Bits
float128_t is always 128 bits

If you use

#ifdef USE_128_BIT_DOUBLE
#include <float128.h>
typedef float128_t Float;
#else
typedef long double Float;
#endif

Now always use "Float" in your code. Then, just with a command line 
flag, you could switch between 80 and 128 bit representations.

[toc] | [prev] | [next] | [standalone]

#66536

jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 29/07/2015 17:51, Keith Thompson a écrit :
>> Keith Thompson <kst-u@mib.org> writes:
>>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>> [...]
>>>> lcc-win has two implementations of long double: the "standard" intel 80
>>>> bits long double in hardware (FPU) and a software implementation of 128
>>>> bit long doubles (called float128_t)
>> [...]
>>> BTW, I'm curious about your two different implementations of long
>>> double, 80 and 128 bits.  How do you specify which one you want
>>> to use?  If it's a compile-time option, does the linker prevent
>>> you from linking object files that don't use the same representation?
>>
>> You posted a followup to the above post, but you didn't answer the
>> quoted question.
>>
>> Can lcc-win treat your float128_t type as "long double", or is
>> float128_t always a distinct type?  If the size of long double is
>> configurable, how do you avoid mixing code using 80-bit long double
>> with code using 128-bit long double?
>
> Read the message I posted:
>
> lcc-win has two implementations of long double: the "standard" intel 80
> bits long double in hardware (FPU) and a software implementation of 128
> bit long doubles (called float128_t)
>
> long double is always Intel's 80 bits FPU representation
> float128_t is a distinct type that *could* be used as long double but 
> this is NOT done by the compiler since the software implementation is 
> 100 times slower than the hardware one...
>
> So: long double is always 80 Bits
> float128_t is always 128 bits
>
> If you use
>
> #ifdef USE_128_BIT_DOUBLE
> #include <float128.h>
> typedef float128_t Float;
> #else
> typedef long double Float;
> #endif
>
> Now always use "Float" in your code. Then, just with a command line 
> flag, you could switch between 80 and 128 bit representations.

Ok, thank you for the clarification.  So there's no issue of linking
translation units that use different representations for long
double; it's always 80 bits.  (Combining object files generated by
lcc-win with object files generated by Microsoft's compiler could
be problematic, assuming that's even supported, but I won't get
into that.)

BTW, I did read your message, which is why I asked the question.
You wrote:

    lcc-win has two implementations of long double: the "standard" intel
                                    --------------
    80 bits long double in hardware (FPU) and a software implementation
    of 128 bit long doubles (called float128_t)
       --------------------

In fact you have only an 80-bit implementation of "long double",
and a 128-bit floating-point type that *isn't* "long double".

Again, thank you for the clarification.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#66355

On Sat, 25 Jul 2015 06:12:16 -0700 (PDT), Malcolm McLean
<malcolm.mclean5@btinternet.com> wrote:

>On Saturday, July 25, 2015 at 1:32:37 PM UTC+1, Kenny McCormack wrote:
>> In article <mourp8$mf$1@dont-email.me>,
>> James Kuyper  <jameskuyper@verizon.net> wrote:
>> >Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> >...
>> >> It's more likely that the tiff reader will be run on a machine
>> >> that doesn't support long double ...
>> >
>> >How many implementations of C do you know of that fail to conform to the
>> >C standard by not supporting long double?
>> 
>> Now, *that* is a rhetorical question.
>> 
>> Seriously, are you really looking for a numerical answer?
>> 
>But it's a fair enough point. If the strategy is to put all scalars
>into a common format, then the question of whether we can rely on
>long double being present or not is important. Actually legitimate
>values in a tiff file for a tiff reader can't go over 2^50 as far as 
>I know, so double is OK.


Doubles are required to have 2**50 in their range, but are not
required to have 50 bits of precision.  IOW, you are guaranteed to be
able to store 2**50, but it may not be distinguishable from
((2**50)-1).

I'll leave the determination of whether or not all valid values in a
TIFF file are under ~2**50 in magnitude to you, but it's crucial that
you actually edit the values you're converting so that they don't
overflow, or are otherwise unrepresentable, in your internal
representation.  Alternatively you could guarantee that overflows will
be harmless (FSVO "harmless"), although that seems much harder.  This
is 2015, and under almost no circumstances can an externally sourced
file be assumed to not be maliciously constructed.

[toc] | [prev] | [next] | [standalone]

#66356

On Saturday, July 25, 2015 at 9:46:03 PM UTC+1, robert...@yahoo.com wrote:
> 
> >But it's a fair enough point. If the strategy is to put all scalars
> >into a common format, then the question of whether we can rely on
> >long double being present or not is important. Actually legitimate
> >values in a tiff file for a tiff reader can't go over 2^50 as far as 
> >I know, so double is OK.
> 
> 
> Doubles are required to have 2**50 in their range, but are not
> required to have 50 bits of precision.  IOW, you are guaranteed to be
> able to store 2**50, but it may not be distinguishable from
> ((2**50)-1).
> 
> I'll leave the determination of whether or not all valid values in a
> TIFF file are under ~2**50 in magnitude to you, but it's crucial that
> you actually edit the values you're converting so that they don't
> overflow, or are otherwise unrepresentable, in your internal
> representation.  Alternatively you could guarantee that overflows will
> be harmless (FSVO "harmless"), although that seems much harder.  This
> is 2015, and under almost no circumstances can an externally sourced
> file be assumed to not be maliciously constructed.
>
TIFF files allow values to be entered as 32 bit longs. A byte buffer
could easily use most of this range (the standard suggests limiting
buffers to about 8K, but this isn't enforced). The realistic risk
is that we'll need to multiply two 32 values, and end up with
a valid seeming but actually wrong answer, and a buffer overflow
attack.
Doubles help because the result should still be representable.
It won't be accurate, but it will be obviously out of the
sensible range, and thus easier to reject.

But making the reader robust to any attack whatsoever is a major
challenge when writing it in C. Lib Tiff has suffered from exactly
that problem. 

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web