I will only talk for the addition. The subtraction is exactly the same.
Currently we only have uaddCarry which only produce carry out, but does not consume carry in.
uaddCarry can only serve as the first stage of extended-precision arithmetic. For the next stages we need a primitive that consumes the carry from the previous stage.
Of course we can simulate it with several extra operation but it is slower. uaddCarry also can be simulated (even with fewer operations) but still we have it.
Please add such function to GLSL. Something like uaddExtended(uint x, uint x, uint carry_in, out uint carry_out).
Every GPU and CPU architecture has native instructions for such operations (with the notable exception of MIPS, it neither has the analogue of uaddCarry).
I can not understand why they only added uaddCarry but not the complete extended-arithmetic primitive set. What are we supposed to do with uaddCarry alone?
It may be better the carry_in/carry_out bits to be implicit/hidden instead of explicit argument to the function because this way it will be closer to the actual hardware.
Otherwise the compiler may have hard time to extract the hidden hardware carry to a visible register and still keep the code as fast as possible.
About the name: the ‘u’ in the function name is superfluous. The arguments are logically neither signed nor unsigned by themselves - they are rather a part of extended operands that span multiple registers/variables. Or if you want to look at them as unsigned, then the “u” is still superfluous as it is implied by the “Carry” part and iaddCarry or saddCarry would not make any sense.