Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #81702 > unrolled thread
| Started by | wij <wyniijj@gmail.com> |
|---|---|
| First post | 2021-10-01 08:37 -0700 |
| Last post | 2021-10-03 18:46 -0700 |
| Articles | 20 on this page of 103 — 17 participants |
Back to article view | Back to comp.lang.c++
How to get mantissa of long double? wij <wyniijj@gmail.com> - 2021-10-01 08:37 -0700
Re: How to get mantissa of long double? RadicalRabbit@theburrow.co.uk - 2021-10-01 16:09 +0000
Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-01 14:05 -0400
Re: How to get mantissa of long double? wij <wyniijj@gmail.com> - 2021-10-01 17:23 -0700
Re: How to get mantissa of long double? Manfred <noname@add.invalid> - 2021-10-02 18:58 +0200
Re: How to get mantissa of long double? Manfred <noname@add.invalid> - 2021-10-02 19:21 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-01 19:18 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-01 19:20 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-01 19:25 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-01 19:53 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-03 08:09 +0200
Re: How to get mantissa of long double? Bart <bc@freeuk.com> - 2021-10-03 11:15 +0100
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-03 12:19 +0200
Re: How to get mantissa of long double? red floyd <no.spam@its.invalid> - 2021-10-03 18:03 -0700
Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-04 09:52 +0200
Re: How to get mantissa of long double? Juha Nieminen <nospam@thanks.invalid> - 2021-10-04 09:59 +0000
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-04 13:50 +0200
Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-04 20:04 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-05 07:12 +0200
Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-05 09:47 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-05 16:46 +0200
Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-05 19:04 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-05 19:13 +0200
Re: How to get mantissa of long double? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-05 09:04 -0700
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-05 19:14 +0200
Re: How to get mantissa of long double? Bart <bc@freeuk.com> - 2021-10-05 19:21 +0100
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-06 07:58 +0200
Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-06 08:11 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-06 10:25 +0200
Re: How to get mantissa of long double? scott@slp53.sl.home (Scott Lurndal) - 2021-10-06 14:25 +0000
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-06 16:53 +0200
Re: How to get mantissa of long double? Bart <bc@freeuk.com> - 2021-10-06 12:12 +0100
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-06 14:48 +0200
Re: How to get mantissa of long double? red floyd <no.spam.here@its.invalid> - 2021-10-06 09:44 -0700
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-06 18:52 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-06 19:02 +0200
Re: How to get mantissa of long double? Juha Nieminen <nospam@thanks.invalid> - 2021-10-07 05:35 +0000
Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-07 08:20 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-07 08:38 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-07 08:42 +0200
Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-07 10:23 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-08 20:23 +0200
Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-09 10:23 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-09 10:50 +0200
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-09 09:02 +0000
Re: How to get mantissa of long double? scott@slp53.sl.home (Scott Lurndal) - 2021-10-09 14:57 +0000
Re: How to get mantissa of long double? Bart <bc@freeuk.com> - 2021-10-09 12:16 +0100
Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-09 15:10 +0200
Re: How to get mantissa of long double? red floyd <no.spam.here@its.invalid> - 2021-10-09 10:26 -0700
Re: How to get mantissa of long double? Vir Campestris <vir.campestris@invalid.invalid> - 2021-10-12 21:23 +0100
Re: How to get mantissa of long double? RadicalRabbit@theburrow.co.uk - 2021-10-13 10:30 +0000
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-07 08:38 +0200
Re: How to get mantissa of long double? Juha Nieminen <nospam@thanks.invalid> - 2021-10-08 04:37 +0000
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-08 07:54 +0200
Re: How to get mantissa of long double? red floyd <no.spam.here@its.invalid> - 2021-10-07 22:44 -0700
Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-07 08:17 +0200
Re: How to get mantissa of long double? Juha Nieminen <nospam@thanks.invalid> - 2021-10-08 04:39 +0000
Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-08 09:25 +0200
Re: How to get mantissa of long double? scott@slp53.sl.home (Scott Lurndal) - 2021-10-08 14:34 +0000
Re: How to get mantissa of long double? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-06 13:57 -0700
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-05 19:34 +0000
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-05 19:33 +0000
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-05 10:19 +0000
Re: How to get mantissa of long double? Bart <bc@freeuk.com> - 2021-10-04 14:06 +0100
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-04 16:12 +0200
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 16:15 +0000
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 16:15 +0000
Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-05 09:48 +0200
Re: How to get mantissa of long double? Juha Nieminen <nospam@thanks.invalid> - 2021-10-05 05:19 +0000
Re: How to get mantissa of long double? David Brown <david.brown@hesbynett.no> - 2021-10-05 10:00 +0200
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-05 16:47 +0200
Re: How to get mantissa of long double? scott@slp53.sl.home (Scott Lurndal) - 2021-10-04 14:37 +0000
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-04 16:53 +0200
Re: How to get mantissa of long double? scott@slp53.sl.home (Scott Lurndal) - 2021-10-04 17:08 +0000
Re: How to get mantissa of long double? Bart <bc@freeuk.com> - 2021-10-04 20:22 +0100
Re: How to get mantissa of long double? Bart <bc@freeuk.com> - 2021-10-01 19:09 +0100
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-01 20:16 +0200
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-01 18:53 +0000
Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-01 20:19 -0400
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-02 02:16 +0000
Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-02 01:28 -0400
Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-02 01:56 -0400
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-02 10:59 +0000
Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-02 14:57 -0400
Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-02 15:37 -0400
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-03 00:47 +0000
Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-03 23:42 -0400
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 04:35 +0000
Re: How to get mantissa of long double? Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-02 12:09 +0200
Re: How to get mantissa of long double? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-10-02 21:00 +0200
Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-02 15:12 -0400
Re: How to get mantissa of long double? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-10-02 21:23 +0200
Re: How to get mantissa of long double? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-10-02 21:27 +0200
Re: How to get mantissa of long double? Manfred <noname@add.invalid> - 2021-10-02 23:19 +0200
Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-03 23:43 -0400
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-03 00:45 +0000
Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-03 23:31 -0400
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 04:34 +0000
Re: How to get mantissa of long double? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-04 11:30 -0400
Re: How to get mantissa of long double? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 16:19 +0000
Re: How to get mantissa of long double? wij <wyniijj@gmail.com> - 2021-10-03 00:35 -0700
Re: How to get mantissa of long double? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-10-03 15:02 +0100
Re: How to get mantissa of long double? wij <wyniijj@gmail.com> - 2021-10-03 18:46 -0700
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | Branimir Maksimovic <branimir.maksimovic@icloud.com> |
|---|---|
| Date | 2021-10-05 19:34 +0000 |
| Message-ID | <sN17J.38841$6u6.20436@fx03.iad> |
| In reply to | #81865 |
On 2021-10-05, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 05.10.2021 um 18:04 schrieb Keith Thompson:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 05/10/2021 07:12, Bonita Montero wrote:
>>>> Am 04.10.2021 um 20:04 schrieb David Brown:
>>>>
>>>>> MSVC for ARM has 64-bit "long doubles" even on 64-bit ARM, other 64-bit
>>>>> ARM targets have 128-bit (I don't know off-hand if they are IEEE quad
>>>>> precision). For RISC-V, even 32-bit targets have 128-bit "long double".
>>>>
>>>> There isn't any ARM-implementation with 128 bit FP.
>>>
>>> And you know that because ... what? Because you are confusing hardware
>>> floating point with floating point in general?
>>
>> $ uname -m
>> aarch64
>> $ cat c.c
>> #include <stdio.h>
>> #include <limits.h>
>> #include <float.h>
>>
>> int main(void) {
>> printf("sizeof (long double) = %zu (%zu bits), LDBL_DIG = %d\n",
>> sizeof (long double),
>> CHAR_BIT * sizeof (long double),
>> LDBL_DIG);
>> }
>> $ gcc c.c -o c && ./c
>> sizeof (long double) = 16 (128 bits), LDBL_DIG = 33
>> $
>
> That's pure software - your CPU doesn't natively support 128 bit FP.
>
Exactly.
--
7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@icloud.com> |
|---|---|
| Date | 2021-10-05 19:33 +0000 |
| Message-ID | <EM17J.38840$6u6.8080@fx03.iad> |
| In reply to | #81862 |
On 2021-10-05, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 05/10/2021 07:12, Bonita Montero wrote:
>>> Am 04.10.2021 um 20:04 schrieb David Brown:
>>>
>>>> MSVC for ARM has 64-bit "long doubles" even on 64-bit ARM, other 64-bit
>>>> ARM targets have 128-bit (I don't know off-hand if they are IEEE quad
>>>> precision). For RISC-V, even 32-bit targets have 128-bit "long double".
>>>
>>> There isn't any ARM-implementation with 128 bit FP.
>>
>> And you know that because ... what? Because you are confusing hardware
>> floating point with floating point in general?
>
> $ uname -m
> aarch64
> $ cat c.c
> #include <stdio.h>
> #include <limits.h>
> #include <float.h>
>
> int main(void) {
> printf("sizeof (long double) = %zu (%zu bits), LDBL_DIG = %d\n",
> sizeof (long double),
> CHAR_BIT * sizeof (long double),
> LDBL_DIG);
> }
> $ gcc c.c -o c && ./c
> sizeof (long double) = 16 (128 bits), LDBL_DIG = 33
> $
>
Apple M1:
bmaxa@Branimirs-Air projects % gcc -O2 c.c
bmaxa@Branimirs-Air projects % ./a.out
sizeof (long double) = 8 (64 bits), LDBL_DIG = 15
bmaxa@Branimirs-Air projects % uname -m
arm64
--
7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@icloud.com> |
|---|---|
| Date | 2021-10-05 10:19 +0000 |
| Message-ID | <sEV6J.56036$md6.10997@fx36.iad> |
| In reply to | #81850 |
On 2021-10-05, Bonita Montero <Bonita.Montero@gmail.com> wrote: > Am 04.10.2021 um 20:04 schrieb David Brown: > >> MSVC for ARM has 64-bit "long doubles" even on 64-bit ARM, other 64-bit >> ARM targets have 128-bit (I don't know off-hand if they are IEEE quad >> precision). For RISC-V, even 32-bit targets have 128-bit "long double". > > There isn't any ARM-implementation with 128 bit FP. > not on Apple, as well... -- 7-77-777 Evil Sinner! to weak you should be meek, and you should brainfuck stronger https://github.com/rofl0r/chaos-pp
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-10-04 14:06 +0100 |
| Message-ID | <sjeu95$ogj$1@dont-email.me> |
| In reply to | #81823 |
On 04/10/2021 08:52, David Brown wrote:
> On 03/10/2021 12:19, Bonita Montero wrote:
>> Am 03.10.2021 um 12:15 schrieb Bart:
>>
>>> Jesus. And I think this still doesn't do an actual long double!
>>
>> long double isn't supported by many compilers for x86-64.
>> long double should be avoided when possible because loads
>> and stores are slow with long double.
>>
>
> "long double" is supported by any C++ or C compiler, for any target,
> that tries to come close to any current standards compliance.
>
> What you probably mean is that on some targets, "long double" is the
> same size as "double". That's true for most 32-bit (and smaller)
> targets. Most 64-bit targets support larger "long double".
Any code running on x86 can choose to use x87 instructions for floating
point.
Then, even calculations involving 64-bit variables, will use 80-bit
intermediate results.
> As happens so often, there is /one/ major exception to the common
> practices used by (AFAICS) every other OS, every other processor, every
> other compiler manufacturer - on Windows, and with MSVC, "long double"
> is 64-bit.
Here's quick survey of Windows C compilers:
Compiler sizeof(long double)
MSCV 8 bytes
gcc 16
clang 8
DMC 10
lccwin 16
tcc 8
bcc 8
So, some compilers do manage to use a wider long double type, even on
Windows, showing that the choice is nothing do with the OS.
And at least one 'big' compiler that is not MSVC also uses a 64-bit type
for long double.
You just like having a bash at Windows (it doesn't stop the use of
float80), and at MSVC (Clang doesn't support float80 either).
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-10-04 16:12 +0200 |
| Message-ID | <sjf255$mu7$1@dont-email.me> |
| In reply to | #81828 |
Am 04.10.2021 um 15:06 schrieb Bart: > DMC 10 > lccwin 16 Irrelevant.
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@icloud.com> |
|---|---|
| Date | 2021-10-04 16:15 +0000 |
| Message-ID | <LMF6J.72292$ol1.29147@fx42.iad> |
| In reply to | #81829 |
On 2021-10-04, Bonita Montero <Bonita.Montero@gmail.com> wrote: > Am 04.10.2021 um 15:06 schrieb Bart: > >> DMC 10 >> lccwin 16 > > > Irrelevant. Irrelevant to whom? -- 7-77-777 Evil Sinner! to weak you should be meek, and you should brainfuck stronger https://github.com/rofl0r/chaos-pp
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@icloud.com> |
|---|---|
| Date | 2021-10-04 16:15 +0000 |
| Message-ID | <kMF6J.72291$ol1.52972@fx42.iad> |
| In reply to | #81828 |
On 2021-10-04, Bart <bc@freeuk.com> wrote: > > Any code running on x86 can choose to use x87 instructions for floating > point. Only in assembler... > -- 7-77-777 Evil Sinner! to weak you should be meek, and you should brainfuck stronger https://github.com/rofl0r/chaos-pp
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-10-05 09:48 +0200 |
| Message-ID | <sjh00m$pnt$2@dont-email.me> |
| In reply to | #81835 |
On 04/10/2021 18:15, Branimir Maksimovic wrote: > On 2021-10-04, Bart <bc@freeuk.com> wrote: >> >> Any code running on x86 can choose to use x87 instructions for floating >> point. > > Only in assembler... > Or with a good compiler.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-10-05 05:19 +0000 |
| Message-ID | <sjgn8l$12bp$1@gioia.aioe.org> |
| In reply to | #81828 |
Bart <bc@freeuk.com> wrote: > Here's quick survey of Windows C compilers: > > Compiler sizeof(long double) > > MSCV 8 bytes > gcc 16 > clang 8 > DMC 10 > lccwin 16 > tcc 8 > bcc 8 Note that sizeof() doesn't tell how large the floating point number is, only how much storage space the compiler is reserving for it. Some compilers may well over-reserve space for 80-bit floating point, for alignment reasons (the extra bytes will be unused). sizeof() is telling only if it gives less than 10 for long double.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-10-05 10:00 +0200 |
| Message-ID | <sjh0n9$1mg$1@dont-email.me> |
| In reply to | #81852 |
On 05/10/2021 07:19, Juha Nieminen wrote: > Bart <bc@freeuk.com> wrote: >> Here's quick survey of Windows C compilers: >> >> Compiler sizeof(long double) >> >> MSCV 8 bytes >> gcc 16 >> clang 8 >> DMC 10 >> lccwin 16 >> tcc 8 >> bcc 8 > > Note that sizeof() doesn't tell how large the floating point number is, > only how much storage space the compiler is reserving for it. Some > compilers may well over-reserve space for 80-bit floating point, for > alignment reasons (the extra bytes will be unused). > > sizeof() is telling only if it gives less than 10 for long double. > Yes, that is an important distinction - especially in the x86 world where different sizes are common. "long double" is typically 80-bit floating point on x86 (except MSVC and weaker tools), but for alignment purposes it is often stored in 16-byte blocks (on 64-bit) or 12-byte blocks (on 32-bit). On other targets (or gcc for x86 with particular flags), "long double" is often quad precision, almost always implemented in software. A useful value to look at is "LDBL_DIG" in <float.h>. For 32-bit IEEE floats, the number of digits is 6. For 64-bit, it is 15. For 80-bit, it is 18. For 128-bit, it is 33.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-10-05 16:47 +0200 |
| Message-ID | <sjhoic$p11$2@dont-email.me> |
| In reply to | #81852 |
Am 05.10.2021 um 07:19 schrieb Juha Nieminen: > Bart <bc@freeuk.com> wrote: >> Here's quick survey of Windows C compilers: >> >> Compiler sizeof(long double) >> >> MSCV 8 bytes >> gcc 16 >> clang 8 >> DMC 10 >> lccwin 16 >> tcc 8 >> bcc 8 > > Note that sizeof() doesn't tell how large the floating point number is, > only how much storage space the compiler is reserving for it. Some > compilers may well over-reserve space for 80-bit floating point, for > alignment reasons (the extra bytes will be unused). If you have a) an x86-Platform and b) sizeof(long double) > 8 then the bits stored inside the long double are 80.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-10-04 14:37 +0000 |
| Message-ID | <ZkE6J.50422$3p3.11006@fx16.iad> |
| In reply to | #81823 |
David Brown <david.brown@hesbynett.no> writes:
>On 03/10/2021 12:19, Bonita Montero wrote:
>
>"long double" should not be used where "double" will do, because it can
>be a great deal slower on many platforms (the load and saves are
>irrelevant). You also have to question whether "long double" does what
>you want, on any given target. On smaller targets (or more limited
>compilers, like MSVC), it gives you no benefits in accuracy or range
>compared to "double". On some, such as x86-64 with decent tools, it
>generally gives you 80-bit types. On others - almost any other 64-bit
>system - it gives you 128-bit quad double, but it is likely to be
>implemented in software rather than hardware.
ARMv8 has 128-bit floating point, in hardware.
FWIW, it also has 512 to 2048 bit floating point, in hardware, when
the SVE extension is implemented.
From the ARMv8 ARM (Architecture Reference Manual):
The architecture also supports the following floating-point data types:
· Half-precision, see Half-precision floating-point formats
on page A1-44 for details.
· Single-precision, see Single-precision floating-point format
on page A1-46 for details.
· Double-precision, see Double-precision floating-point format
on page A1-47 for details.
· BFloat16, see BFloat16 floating-point format on page A1-48
for details.
It also supports:
· Fixed-point interpretation of words and doublewords. See
Fixed-point format on page A1-50.
· Vectors, where a register holds multiple elements, each of
the same data type. See Vector formats on
page A1-41 for details.
The Armv8 architecture provides two register files:
· A general-purpose register file.
· A SIMD&FP register file.
In each of these, the possible register widths depend on the Execution state.
In AArch64 state:
· A general-purpose register file contains thirty-two 64-bit registers:
-- Many instructions can access these registers as 64-bit
registers or as 32-bit registers, using only the
bottom 32 bits.
· A SIMD&FP register file contains thirty-two 128-bit registers:
-- The quadword integer data types only apply to the SIMD&FP
register file.
-- The floating-point data types only apply to the SIMD&FP
register file.
-- While the AArch64 vector registers support 128-bit vectors,
the effective vector length can be 64-bits
or 128-bits depending on the A64 instruction encoding used,
see Instruction Mnemonics on page C1-195.
If the SVE extension is implemented, an additional register file of 32
512-bit to 2048-bit registers (implementation choice) is available).
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-10-04 16:53 +0200 |
| Message-ID | <sjf4gq$ag2$1@dont-email.me> |
| In reply to | #81831 |
Am 04.10.2021 um 16:37 schrieb Scott Lurndal: > ARMv8 has 128-bit floating point, in hardware. > FWIW, it also has 512 to 2048 bit floating point, > in hardware, when the SVE extension is implemented. I bet that ther even isn't an implementation for 128 bit fp, but just a specification.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-10-04 17:08 +0000 |
| Message-ID | <ZxG6J.34878$j52.29185@fx18.iad> |
| In reply to | #81831 |
scott@slp53.sl.home (Scott Lurndal) writes:
>David Brown <david.brown@hesbynett.no> writes:
>>On 03/10/2021 12:19, Bonita Montero wrote:
>
>>
>>"long double" should not be used where "double" will do, because it can
>>be a great deal slower on many platforms (the load and saves are
>>irrelevant). You also have to question whether "long double" does what
>>you want, on any given target. On smaller targets (or more limited
>>compilers, like MSVC), it gives you no benefits in accuracy or range
>>compared to "double". On some, such as x86-64 with decent tools, it
>>generally gives you 80-bit types. On others - almost any other 64-bit
>>system - it gives you 128-bit quad double, but it is likely to be
>>implemented in software rather than hardware.
>
>
>ARMv8 has 128-bit floating point, in hardware.
^ registers
It does not support 128-bit float point types.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-10-04 20:22 +0100 |
| Message-ID | <sjfkam$crq$1@dont-email.me> |
| In reply to | #81842 |
On 04/10/2021 18:08, Scott Lurndal wrote: > scott@slp53.sl.home (Scott Lurndal) writes: >> David Brown <david.brown@hesbynett.no> writes: >>> On 03/10/2021 12:19, Bonita Montero wrote: >> >>> >>> "long double" should not be used where "double" will do, because it can >>> be a great deal slower on many platforms (the load and saves are >>> irrelevant). You also have to question whether "long double" does what >>> you want, on any given target. On smaller targets (or more limited >>> compilers, like MSVC), it gives you no benefits in accuracy or range >>> compared to "double". On some, such as x86-64 with decent tools, it >>> generally gives you 80-bit types. On others - almost any other 64-bit >>> system - it gives you 128-bit quad double, but it is likely to be >>> implemented in software rather than hardware. >> >> >> ARMv8 has 128-bit floating point, in hardware. > ^ registers > > It does not support 128-bit float point types. > So it doesn't support float512 to float2048 in hardware? I thought that sounded far-fetched. But if it's just a matter of registers of 128+ bits (which can store a vector of smaller float types), then that's old hat with x86/x64.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-10-01 19:09 +0100 |
| Message-ID | <sj7it1$6nb$2@dont-email.me> |
| In reply to | #81704 |
On 01/10/2021 18:18, Bonita Montero wrote: > Am 01.10.2021 um 17:37 schrieb wij: >> // numeric_limits<long double>::digits=64. >> // >> typedef long double FType; >> FType x=numeric_limits<FType>::max(); >> int iexp; >> int64_t mint; >> x=::frexpl(x,&iexp); >> x=::ldexpl(x,numeric_limits<FType>::digits); >> mint= static_cast<int64_t>(x); >> >> Result (mint) is a negative number, something not right!!! > > Take this: > > #include <iostream> > #include <cstdint> > #include <limits> > #include <utility> > #include <iomanip> > > using namespace std; > > using mantissa_pair = pair<bool, uint64_t>; > > mantissa_pair getMantissa( double value ); What happened to *long* double?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-10-01 20:16 +0200 |
| Message-ID | <sj7jad$b6m$1@dont-email.me> |
| In reply to | #81710 |
Am 01.10.2021 um 20:09 schrieb Bart: > On 01/10/2021 18:18, Bonita Montero wrote: >> Am 01.10.2021 um 17:37 schrieb wij: >>> // numeric_limits<long double>::digits=64. >>> // >>> typedef long double FType; >>> FType x=numeric_limits<FType>::max(); >>> int iexp; >>> int64_t mint; >>> x=::frexpl(x,&iexp); >>> x=::ldexpl(x,numeric_limits<FType>::digits); >>> mint= static_cast<int64_t>(x); >>> >>> Result (mint) is a negative number, something not right!!! >> >> Take this: >> >> #include <iostream> >> #include <cstdint> >> #include <limits> >> #include <utility> >> #include <iomanip> >> >> using namespace std; >> >> using mantissa_pair = pair<bool, uint64_t>; >> >> mantissa_pair getMantissa( double value ); > > What happened to *long* double? Is idiocracy.
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@icloud.com> |
|---|---|
| Date | 2021-10-01 18:53 +0000 |
| Message-ID | <SOI5J.60525$2B4.50814@fx04.iad> |
| In reply to | #81702 |
On 2021-10-01, wij <wyniijj@gmail.com> wrote: > // numeric_limits<long double>::digits=64. > // > typedef long double FType; > FType x=numeric_limits<FType>::max(); > int iexp; > int64_t mint; > x=::frexpl(x,&iexp); > x=::ldexpl(x,numeric_limits<FType>::digits); > mint= static_cast<int64_t>(x); > > Result (mint) is a negative number, something not right!!! long double max = cumeric_limits<long double>::max(); long mantissa = max; // impicit conversion -- 7-77-777 Evil Sinner!
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-10-01 20:19 -0400 |
| Message-ID | <sj88ir$aub$2@dont-email.me> |
| In reply to | #81713 |
On 10/1/21 2:53 PM, Branimir Maksimovic wrote: ... > long double max = cumeric_limits<long double>::max(); > long mantissa = max; // impicit conversion "A prvalue of a floating-point type can be converted to a prvalue of an integer type. The conversion truncates; that is, the fractional part is discarded. The behavior is undefined if the truncated value cannot be represented in the destination type." (7.3.10p1). While it's not required to be the case, on most implementations std::numeric_limits<long double>::max() is WAY too large to be represented by a long, so the behavior of such code is undefined. The minimum value of LDBL_MAX (set by the C standard, inherited by the C++ standard) is 1e37, which would require long to have at least 123 bits in order for that conversion to have defined behavior. And even when it has defined behavior, I can't imagine how you would reach the conclusion that this conversion should be the value of the mantissa.
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@icloud.com> |
|---|---|
| Date | 2021-10-02 02:16 +0000 |
| Message-ID | <OhP5J.60529$2B4.27684@fx04.iad> |
| In reply to | #81726 |
On 2021-10-02, James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > On 10/1/21 2:53 PM, Branimir Maksimovic wrote: > ... >> long double max = cumeric_limits<long double>::max(); >> long mantissa = max; // impicit conversion > "A prvalue of a floating-point type can be converted to a prvalue of an > integer type. The conversion truncates; that is, the fractional part is > discarded. The behavior is undefined if the truncated value cannot be > represented in the destination type." (7.3.10p1). > > While it's not required to be the case, on most implementations > std::numeric_limits<long double>::max() is WAY too large to be > represented by a long, so the behavior of such code is undefined. The > minimum value of LDBL_MAX (set by the C standard, inherited by the C++ > standard) is 1e37, which would require long to have at least 123 bits in > order for that conversion to have defined behavior. > And even when it has defined behavior, I can't imagine how you would > reach the conclusion that this conversion should be the value of the > mantissa. It is not undefined as long is larger then mantissa part. ok correct is long long :P -- 7-77-777 Evil Sinner!
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.c++
csiph-web