C++ Logo


Advanced search

Re: [std-proposals] Integer overflow arithmetic

From: Tiago Freire <tmiguelf_at_[hidden]>
Date: Sun, 18 Feb 2024 17:19:01 +0000

Look I don’t want 128bit operations. I want to do operations of arbitrary size.
128 bit operations are implemented in terms of these functions. That is what makes it work!

> - You can implement mul_wide in terms of 128-bit multiplication between two 64-bit operands.
> - You can implement add_wide in terms of 128-bit addition between two 64-bit operands.
> - You can implement div_wide in terms of 128-bit division with a 64-bit divisor.
> - You can add [[assume]] to match the semantics of your function exactly.
> - You can implement rem_wide in terms of 128-bit division.

That's just BS! mul_wide, add_carry, sub_borrow, div_wide, is what makes 128bit operations work. It always has!
You can't tell me that you can implement this with 128bit operations, when you open the source code to see how 128bit operations are actually implemented, look surprise surprise they are done in terms of these functions.
I just showed you how they have been implemented! They not only used it in the exact same way, but they also went to the trouble of creating routines to emulate the function on platforms that have no native instruction for it!
Your ideas about this are completely backwards!

Why do I have to do this inane 64bit to 128bit operations to coax out these operations?
Why can't I just ditch 128bit casts and just get the functions that I want to begin with?
Why do people have to constantly re-write this function in assembly? why do I have to keep re-inventing the wheel?
Please explain to me how making a call to __umodti3, for it to internally realize "oh shit let's do a div_wide instead" is better than just call "div_wide" myself?
Why are you being a gate keeper?
This is absolutely insane!
This is not new, they have been doing this back at least since 1985, it's 2024! Why should I be banging rocks?

Next thing you will tell me that we should remove regular division from the language because only x86 has them.

Received on 2024-02-18 17:19:04