> 128 bit operations are implemented in terms of these functions. That is what makes it work!

I think we're talking past each other on this one. I'm talking about
how the user of the C++ language can obtain these operations when they
have a 128-bit integer.

Keep in mind that for addition and multiplication, the compiler emits
the instructions directly and doesn't make any call to an internal
mul_wide or add_wide style function. This invalidates the argument
that 128-bit integers are implemented in terms of these.

Division is the one exception. At best, this is an implementation
detail which ultimately isn't relevant to the proposal. At worst, it's
a missed optimization and the compiler simply didn't emit a DIV
instruction in specific cases where it would be much faster than to
call a function.

You're completely missing the point and projecting details of specific
implementations and architectures onto the C++ language.

If the user can EXPRESS widening multiplication using a 128-bit
integer, then why is that not the best approach. Who cares about the
specifics of how that operation is implemented. It is a good way to
EXPRESS the operation in the C++ language, and in principle, the
codegen can be optimal. If it isn't, that's a
quality-of-implementation issue and not relevant to the C++ standard.

> Why do I have to do this inane 64bit to 128bit operations to coax out these operations?

If you had 128-bit integers, then you wouldn't need these functions.
128-bit integers are the better INTERFACE to EXPRESS the operation in
C++.

> Why can't I just ditch 128bit casts and just get the functions that I want to begin with?

Why would you ditch them? (uint128_t) x * y is much more ergonomic
than auto [hi, low] = mul_wide(x, y); ...

> Why do people have to constantly re-write this function in assembly? why do I have to keep re-inventing the wheel?

Because there is no standard way to express it yet. That doesn't mean
that modeling the standard after x86 assembly instructions is a good
idea.

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

It's not. You just don't realize that no one is forcing clang
developers at gunpoint to emit call __umodti3. They can just as well
emit a single or multiple div instructions based on what operation is
needed, and what value constraints the inputs have.

You're assuming that because of how it happens to be right now,
there's literally no way that it could ever be any other way.

> Why are you being a gate keeper?

I'm not. I'm just giving you feedback on your proposal. If I'm
bringing these issues up, people in the future will do that just as
well. Take it or leave it. You could see this as whole conversation as
preparation for when you'll have to defend your proposal in front of
WG21.