|
|
|
This thread is locked; no one can reply to it.
|
| [GCC] __int128_t exists?! |
|
Chris Katko
Member #1,881
January 2002
 |
How what why HOW does this even work? __int128_t x; //yeehhhawwww
6.8 128-bit integers As an extension the integer scalar type __int128 is supported for targets which have an integer mode wide enough to hold 128 bits. Simply write __int128 for a signed 128-bit integer, or unsigned __int128 for an unsigned 128-bit integer. There is no support in GCC for expressing an integer constant of type __int128 for targets with long long integer less than 128 bits wide. I can't find any other data on these at all. It says they require the host system to support it, but it compiles fine and runs. Does my Athlon X4 630 somehow support 128-bit wide integers? When did this become a thing? -----sig: |
|
Arthur Kalliokoski
Second in Command
February 2005
 |
They all watch too much MSNBC... they get ideas. |
|
torhu
Member #2,727
September 2002
 |
Why not look at the assembly output to see how it's implemented? |
|
Thomas Fjellstrom
Member #476
June 2000
 |
Probably supported similar to how 64bit ints were on 32bit hardware. Usually via cpu extensions that support wider vector math. Or with hacks doing two+ operations to get the arithmetic to work. -- |
|
Chris Katko
Member #1,881
January 2002
|
It's likely to be faster, and have less bugs than one I rolled myself! -----sig: |
|
Arthur Kalliokoski
Second in Command
February 2005
|
I just tried compiling this extern __int128_t bignum; void incit(void) { bignum++; } as gcc -S -g -fverbose-asm t.c followed by as -alhnd t.s > t.lst and the relevant part of t.lst says 45 0004 488B0500 movq bignum(%rip), %rax # bignum, bignum.0 45 000000 46 000b 488B1500 movq bignum+8(%rip), %rdx # bignum, bignum.0 46 000000 47 0012 4883C001 addq $1, %rax #, bignum.1 48 0016 4883D200 adcq $0, %rdx #, bignum.1 49 001a 48890500 movq %rax, bignum(%rip) # bignum.1, bignum 49 000000 50 0021 48891500 movq %rdx, bignum+8(%rip) # bignum.1, bignum so it's essentially doing it the same way Turbo C did 32 bit ints as mentioned by Thomas above. They all watch too much MSNBC... they get ideas. |
|
torhu
Member #2,727
September 2002
|
That wouldn't work if there is more than one bit overflow, would it? |
|
Arthur Kalliokoski
Second in Command
February 2005
|
I haven't tried it, but what's supposed to happen is the overflow bit in the flags gets set. OTOH, C doesn't normally check or care about integer overflow. They all watch too much MSNBC... they get ideas. |
|
torhu
Member #2,727
September 2002
|
Yes, and the ADC instruction adds both the carry flag and operand. But what happens if the value is 2^64-1, and then you multiply by four? |
|
Arthur Kalliokoski
Second in Command
February 2005
|
Try that with 32 bit ints and see what happens. They all watch too much MSNBC... they get ideas. |
|
Chris Katko
Member #1,881
January 2002
|
Yeah, I'm a little worried. I'll have to run some tests when I get some free time. What I'm looking for, is large fixed-point math handling for my Kerbal Space Program-like game. The issue is, doubles--as you know--have a exponential precision. That means, the bigger the number, the less precise the number. You can't apply tiny amounts of acceleration to astronomical distances like planets in a solar systems when using doubles. And worse still, when you sum acceleration to get velocity, you get integration errors and integration errors add up fast. My system works fine with some guessed numbers (it may be broken with proper values, I haven't tested!) for a solar system. But the second you "speed up" the simulation by taking larger integration slices for velocity, the planets orbits change and change drastically to the point of all colliding into the sun and gravity slingshot like some sort of orbital rail gun. I did some number calculations that said a 64-bit fixed point should be able to encompass a single solar system and still have pretty good precision. But it'd be nice to test a 128-bit one directly to see if there is any improvement. GNU has an arbitrary precision math library but it will probably be ridiculously slow compared to a hard-coded fixed-point number because the GNU library supports so many complex things. -----sig: |
|
|
