Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 17 Mar 2015 09:07:35 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: 256/128 bit integer arithmatic

On 2015-03-17 06:45, Solar Designer wrote:
>> I tested against unsigned __int128. Are they any different from __uint128_t
>> from performance or portability perspective?
> 
> I'd expect them to be the same performance.  As to portability, I don't
> know.  __uint128_t worked for me even on gcc 3.4.5.

GCC has had __int128_t and __uint128_t for 64-bit targets since 3.1.
There were *no* corresponding macro (like __SIZEOF_INT128__) that showed it.

Since gcc 4.6 or so, this is replaced with __int128 (you'd use 'unsigned
__int128' for unsigned). There *is* now a __SIZEOF_INT128__ defined. The
__int128_t syntax still works but I think it's deprecated. As far as I
know there is no difference in implementation, just the name.

Jumbo's autoconf tests this and sets HAVE___INT128_T and HAVE___INT128
accordingly (and it may set HAVE_INT128 with other compilers).

I use it like this in mpz_int128.h (which is not included at all if none
of the three is set, hence the last catch-all):


#undef int128_t
#define int128_t our_int128_t
#undef uint128_t
#define uint128_t our_uint128_t

#if HAVE___INT128
typedef __int128                int128_t;
typedef unsigned __int128       uint128_t;
#elif HAVE_INT128
typedef int128                  int128_t;
typedef unsigned int128         uint128_t;
#else /* HAVE__INT128_T */
typedef __int128_t              int128_t;
typedef __uint128_t             uint128_t;
#endif

#define UINT128_MAX             ((uint128_t)-1)


That last line is because we can't (even in gcc-5 afaik) express
constants larger than ULL. We could set a positive number using shifts
but the above works fine.

magnum

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ