From nobody Sun Jul 10 04:24:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4F86D1CFD39B for ; Sun, 10 Jul 2022 04:25:00 +0000 (UTC) (envelope-from plmahan@gmail.com) Received: from mail-oa1-x2e.google.com (mail-oa1-x2e.google.com [IPv6:2001:4860:4864:20::2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LgYp32bXsz43N1; Sun, 10 Jul 2022 04:24:59 +0000 (UTC) (envelope-from plmahan@gmail.com) Received: by mail-oa1-x2e.google.com with SMTP id 586e51a60fabf-10bffc214ffso3338848fac.1; Sat, 09 Jul 2022 21:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=57Xr6+i+m5uwIt0ZwzF7ftFpZa6e6qA0O1cci92HcPE=; b=iS4AbaKaf5CgVwK8BahbmpO0x1BvioklDnmUZ37maUD/qD60A5wyUWGHf5/33btvZs +s4COafrsh65wVx250FX9rw4VVfdf/2Eq4+WQLc7p1Sbl2X28OUOnalS3BUYsKWj8ViB YQHNV9XEva1ZCCxBNfOOL63gYpjYhWgv4d4H42UFzVpKk/wxRj/luZR4s9YUgrbuWDZl ONbwI6P6mTYXmewsCnUHcvTVC1qslLkZG6ct1Za3dGgF/9569MVnhxac7hyaevFQip6z q/iUR1+Lr2pf5Pea4ApcQmee4+g0T0ZcUVq0VkSTOx02jlpl0Z9O8pxbunt/UCDvDHsp 16Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=57Xr6+i+m5uwIt0ZwzF7ftFpZa6e6qA0O1cci92HcPE=; b=VhfUrDbFZd6MOiVuP4OGZjDZvEz8eMS2gQH/nUH/P5+RupGbbqUwfp1VPk/1Ntvbst hFqz+VrAAdZ85t6f32H5ms0oJaIWEWhtmYqGumqW4u7UJ27sngnFfk6NuHZeJDXEOc0y LAT2u3bWZ5cRppWvdXrXq6iyFgMkqh09PGHOJeRBDVJhBXvZnzfevtrcXeGMyWuft4kp /9hHz7iK6R2D848ZDg7gNr555xagPaXD7Ekl/QEoe7f3Ek9O4Z9czT6g1ryO97xnhmcd PCrtq/th2v/CgTEBi5xA691U2/UL0ntc4t1+OzBdeRyPInsoHT8aXhm1Ly0ocZ5aiSVo mxVw== X-Gm-Message-State: AJIora8DfHLOKd+ZuBH8bT9PyBt2qA0bJsYhoGKVUV8otNQh6F+r3v7c DNIGVA9Tq73wbfAuYyrdFHUw8pRJ467z8OXJUIcq9w23 X-Google-Smtp-Source: AGRyM1uvkd5OzHqqcmbbD5S+jeJvCQGc0G8sxBn4g9j09zii8a9FpBPvFMgIM/JbihDPyQd4CNZwMvgjup7dv0k5Uu0= X-Received: by 2002:a05:6870:1794:b0:10b:f7b8:af82 with SMTP id r20-20020a056870179400b0010bf7b8af82mr4144394oae.238.1657427098089; Sat, 09 Jul 2022 21:24:58 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <86CB4C22-9CAB-4578-8F11-962B4B08F756@bumblingdork.com> <903B6B84-4AFE-4BB5-94F5-5DFD65BAC1B6@FreeBSD.org> In-Reply-To: <903B6B84-4AFE-4BB5-94F5-5DFD65BAC1B6@FreeBSD.org> From: Patrick Mahan Date: Sat, 9 Jul 2022 21:24:47 -0700 Message-ID: Subject: Re: Canonical way / best practice for 128-bit integers To: Dimitry Andric Cc: Marc Veldman , freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="0000000000006c3c9305e36bd197" X-Rspamd-Queue-Id: 4LgYp32bXsz43N1 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=iS4AbaKa; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of plmahan@gmail.com designates 2001:4860:4864:20::2e as permitted sender) smtp.mailfrom=plmahan@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2001:4860:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2001:4860:4864:20::2e:from]; ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --0000000000006c3c9305e36bd197 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jul 9, 2022 at 10:06 AM Dimitry Andric wrote: > On 9 Jul 2022, at 18:26, Marc Veldman wrote: > > > > I=E2=80=99m working on some bluetooth code, and that involves handling = 128-bit > uuids. > > There are various ways to handle in the FreeBSD codebase, like in sdp.h= : > > > > /* > > * SDP int128/uint128 parameter > > */ > > > > struct int128 { > > int8_t b[16]; > > }; > > typedef struct int128 int128_t; > > typedef struct int128 uint128_t; > > > > and in sys/dev/random/uint128.h > > > > #ifdef USE_REAL_UINT128_T > > typedef __uint128_t uint128_t; > > #define UINT128_ZERO 0ULL > > #else > > typedef struct { > > /* Ignore endianness */ > > uint64_t u128t_word0; > > uint64_t u128t_word1; > > } uint128_t; > > static const uint128_t very_long_zero =3D {0UL,0UL}; > > #define UINT128_ZERO very_long_zero > > #endif > > > > Is there any recommended / standard way to handle 128 bit integers in a > portable way? > > Of course recent compilers have built-in support for __int128_t and > __uint128_t, but it comes with a *lot* of caveats: not supported on all > architectures, definitely never on 32-bit ones, differences between > compilers, and even compiler versions, etc etc. > > If you want it portable, the only way is to handle them as two 64 bit > integers, and leave any arithmetic or conversion to library routines. > > I second this, especially if you want to use any of the underlying assembly code. For example, the Intel architecture supports the data type but does not support 128-bit instructions but instead requires you to shift the upper 64 bits to operate with a 64-bit instruction. I found this out when we needed to speed up the ability to walk a 128-bit bitmask (we were doing it the hard way). I wound up converting everything back to 64-bit and saw a tremendous speed up in our code. I mostly use it for defining the storage of an IP address (either IPv4 or IPv6) where storage does not need to be exceedingly tight. Also, I have only used it on Intel/AMD architectures. Back when I was working in MIPS architectures (mostly Cavium multi-core) we did not have this data type available. And I have only briefly looked at AArch64 so it may or may not be supported there. Patrick --0000000000006c3c9305e36bd197 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jul 9, 2022 at 10:06 AM Dimitry A= ndric <dim@freebsd.org> wrote:=
On 9 Jul 2022, at 18:26, Marc Veldman <marc@bumblingdork.com> wrote:<= br> >
> I=E2=80=99m working on some bluetooth code, and that involves handling= 128-bit uuids.
> There are various ways to handle in the FreeBSD codebase, like in sdp.= h:
>
> /*
> * SDP int128/uint128 parameter
> */
>
> struct int128 {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 int8_t=C2=A0 b[16];
> };
> typedef struct int128=C2=A0 =C2=A0int128_t;
> typedef struct int128=C2=A0 =C2=A0uint128_t;
>
> and in sys/dev/random/uint128.h
>
> #ifdef USE_REAL_UINT128_T
> typedef __uint128_t uint128_t;
> #define UINT128_ZERO 0ULL
> #else
> typedef struct {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Ignore endianness */
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint64_t u128t_word0;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint64_t u128t_word1;
> } uint128_t;
> static const uint128_t very_long_zero =3D {0UL,0UL};
> #define UINT128_ZERO very_long_zero
> #endif
>
> Is there any recommended / standard way to handle 128 bit integers in = a portable way?

Of course recent compilers have built-in support for __int128_t and
__uint128_t, but it comes with a *lot* of caveats: not supported on all
architectures, definitely never on 32-bit ones, differences between
compilers, and even compiler versions, etc etc.

If you want it portable, the only way is to handle them as two 64 bit
integers, and leave any arithmetic or conversion to library routines.


I second this, especially if you want = to use any of the underlying assembly code.=C2=A0 For example, the Intel ar= chitecture supports the data type but does not support 128-bit instructions= but instead requires you to shift the upper=C2=A064 bits to operate with a= 64-bit instruction.

I found this out when we need= ed to speed up the ability to walk a 128-bit bitmask (we were doing it the = hard way).=C2=A0 =C2=A0I wound up converting everything back to 64-bit and = saw a tremendous speed up in our code.

I mostly us= e it for defining the storage of an IP address (either IPv4 or IPv6) where = storage does not need to be exceedingly tight.

Als= o, I have only used it on Intel/AMD architectures.=C2=A0 Back when I was wo= rking in MIPS architectures (mostly Cavium multi-core) we did not have this= data type available.=C2=A0 And I have only briefly looked at AArch64 so it= may or may not be supported there.

Patrick
<= /div>
--0000000000006c3c9305e36bd197--