4 ms·

>> Pretty much every computer that matters works the way you expect it to: the value will overflow, some flag will be set, etc. The compiler couldn't care less

>> Pretty much every computer that matters works the way you expect it to: the value will overflow, some flag will be set, etc. The compiler couldn't care less though. And RISC-V drops the hardware flags entirely. I questioned this when I read it, but "carry" is really only useful in asm code for adding and subtracting integers larger than register size, which is not much of a thing these days. None of the flags are accessible from C either so they just dropped them and things seem to be going well!

matheusmoreira 2y ago
> but "carry" is really only useful in asm code for adding and subtracting integers larger than register size, which is not much of a thing these days Funny you mention that. I'm studying math and algorithms to implement the arbitrary precision integer support for my programming language. The word "carry" is showing up a lot in my research so that bit does seem to be an incredibly useful feature and I have no idea why they'd remove it. > None of the flags are accessible from C either so they just dropped them and things seem to be going well! I know you can't directly access those flags but the fact is compilers do provide their functionality to programmers via builtins. For example: https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins... Those builtins will cause the compiler to generate optimal instructions such as conditional jumps that depend on the carry or overflow bits. I used the __builtin_mul_overflow function to check for overflow in my memory allocation code. This is what we really want. We want to handle these conditions, no matter how they're implemented. This is a perfectly acceptable way for the compiler to expose these processor features in a way that makes sense to us programmers. In the case of RISC-V, GCC will just emit whatever code is appropriate for checking overflows on that processor. What's definitely not acceptable is for the compiler to just go "aw man look at this USELESS overflow checking code over here, AS WE ALL KNOW signed integer overflow is UNDEFINED and therefore CANNOT EVER HAPPEN, why the hell is this shit for brains programmer checking for a thing that can't happen, I'll just go ahead delete this nonsense code literally right now, oh wow would you look at that, looks like I just optimized the entire program into a noop, I must be the best compiler in the universe".

matheusmoreira 2y ago

> but "carry" is really only useful in asm code for adding and subtracting integers larger than register size, which is not much of a thing these days Funny you mention that. I'm studying math and algorithms to implement the arbitrary precision integer support for my programming language. The word "carry" is showing up a lot in my research so that bit does seem to be an incredibly useful feature and I have no idea why they'd remove it. > None of the flags are accessible from C either so they just dropped them and things seem to be going well! I know you can't directly access those flags but the fact is compilers do provide their functionality to programmers via builtins. For example: https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins... Those builtins will cause the compiler to generate optimal instructions such as conditional jumps that depend on the carry or overflow bits. I used the __builtin_mul_overflow function to check for overflow in my memory allocation code. This is what we really want. We want to handle these conditions, no matter how they're implemented. This is a perfectly acceptable way for the compiler to expose these processor features in a way that makes sense to us programmers. In the case of RISC-V, GCC will just emit whatever code is appropriate for checking overflows on that processor. What's definitely not acceptable is for the compiler to just go "aw man look at this USELESS overflow checking code over here, AS WE ALL KNOW signed integer overflow is UNDEFINED and therefore CANNOT EVER HAPPEN, why the hell is this shit for brains programmer checking for a thing that can't happen, I'll just go ahead delete this nonsense code literally right now, oh wow would you look at that, looks like I just optimized the entire program into a noop, I must be the best compiler in the universe".