Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » [GCC] __int128_t exists?!

This thread is locked; no one can reply to it. rss feed Print
[GCC] __int128_t exists?!
Chris Katko
Member #1,881
January 2002
avatar

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:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs
"Political Correctness is fascism disguised as manners" --George Carlin

Arthur Kalliokoski
Second in Command
February 2005
avatar

They all watch too much MSNBC... they get ideas.

torhu
Member #2,727
September 2002
avatar

Why not look at the assembly output to see how it's implemented?

Thomas Fjellstrom
Member #476
June 2000
avatar

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.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Chris Katko
Member #1,881
January 2002
avatar

It's likely to be faster, and have less bugs than one I rolled myself!

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs
"Political Correctness is fascism disguised as manners" --George Carlin

Arthur Kalliokoski
Second in Command
February 2005
avatar

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
avatar

That wouldn't work if there is more than one bit overflow, would it?

Arthur Kalliokoski
Second in Command
February 2005
avatar

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
avatar

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? :o

Arthur Kalliokoski
Second in Command
February 2005
avatar

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
avatar

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:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs
"Political Correctness is fascism disguised as manners" --George Carlin

Go to: