The devil is not in the number representation but in the details. The proposal says:
> Overflowing operations and out-of-range conversion are generally mapped to modulo operations and cannot trap or raise signals.
This would be a problem on x86, where INT_MIN / -1 causes a #DE (divide error) exception.
In C17 that is fine because signed integer overflow is undefined behaviour. But if the behaviour is defined, that trap would have to be caught or avoided.
The best solution for performance would be to have a new trap handler. That would have to parse the instruction to find its length, and the divisor (in memory or register) to differentiate it from division by zero, write the constant result and remainder into the destination registers (always rax and rdx thankfully) and then continue with the next instruction.
But I think this could be difficult to do in a fool-proof way, with how CPU exceptions are handled in different operating systems. Some operating systems might not even allow it at all.
> Overflowing operations and out-of-range conversion are generally mapped to modulo operations and cannot trap or raise signals.
This would be a problem on x86, where INT_MIN / -1 causes a #DE (divide error) exception. In C17 that is fine because signed integer overflow is undefined behaviour. But if the behaviour is defined, that trap would have to be caught or avoided.
The best solution for performance would be to have a new trap handler. That would have to parse the instruction to find its length, and the divisor (in memory or register) to differentiate it from division by zero, write the constant result and remainder into the destination registers (always rax and rdx thankfully) and then continue with the next instruction.
But I think this could be difficult to do in a fool-proof way, with how CPU exceptions are handled in different operating systems. Some operating systems might not even allow it at all.