[Development] Renaming quint128

Thiago Macieira thiago.macieira at intel.com
Fri Nov 18 18:19:27 CET 2022

On Friday, 18 November 2022 04:16:48 PST Shawn Rutledge via Development wrote:
> On 2022 Nov 18, at 03:13, Thiago Macieira
> <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>> wrote:
> > I was working on extended integers and added qint128 and quint128 to
> > qglobal.h
> Interesting.  How far can we go with doubling bits?  quint512 in case you
> have AVX-512 registers?  (I must get a laptop with that feature, next time;
> since even Zen 3 doesn’t have it, I still don’t have any machine that
> does)

That's not the same thing. The 128-bit integers are stored in general-purpose 
registers and exist as a by-product of the compilers having code to work with 
64-bit integers on 32-bit CPU. All the current architectures that went from 32 
to 64-bit simply duplicated their "double word" instructions extending the 
support to 128-bit, so the compilers did the same for their runtime support. 
On x86, that's also the same set of instructions that allowed 32-bit 
operations on the 16-bit processors.

I don't expect this to double again any time soon.

The AVX and AVX-512 registers don't operate as a single 128-, 256- or 512-bit 
integer register. Instead, they operate as a vector of 8-, 16-, 32-, or 64-bit 
entities ("lanes") and perform the same operation in parallel.
> Maybe CBOR bignums would have a use for it?  Various kinds of hashes?  I’d
> really like it if cryptographic hashes often ended up being numeric again.
> QUuid should have a use for it.

Yep, turns out that this was the easiest way to deal with the QBluetoothUuid 
problem. I wrote this unit test yesterday:

    quint128 u = Q_UINT64_C(0xfc69b59ecc344436);
    u <<= 64;
    u |= Q_UINT64_C(0xa43cee95d128b8c5);

    QUuid uuid(u);
    QCOMPARE(uuid, uuidA);
    QCOMPARE(quint64(uuid.toUInt128() >> 64), quint64(u >> 64));
    QCOMPARE(quint64(uuid.toUInt128()), quint64(u));

I split the compares because I haven't added a QTest::toString of 128-bit 
because I didn't extend the number-to-string support to QByteArray & QLocale. 
I only added to QTextStream. See 

> What else can we interoperate with? gmplib.org<http://gmplib.org> perhaps;
> maybe some C++ standard could be in the works?

GMP would be what I'd use to support CBOR bignums. But I don't think we'll 
extend our support there, directly, in QtCore.
> What about having varints in Qt some day?  (Like the way protobuf stores
> ints)  I wonder why CBOR doesn’t have them.
CBOR has "regular integers" that can be any value between -2^64-1 to 2^64. 
It's meant to be similar to JSON where you only have "number", not to enforce 
a serialisation format. It chose to use a single type for integral numbers so 
that all would benefit from being transmitted in fewer bytes in case of small 
numbers, instead of having fixed size to accommodate the full range.

Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering

More information about the Development mailing list