5 ms·

That's hardware specific, right? You're not guaranteed to have a solution on every platform.

by csmpltn 4y ago

mikequinlan 4y ago
All platforms can detect overflow in one way or another; for example by checking for an unexpected sign change.
- chrisseaton 4y ago
  AMD64 addressing modes cannot detect overflow, and this is where in practice 90% of arithmetic is done!
  - mikequinlan 4y ago
    I don't know specific AMD64 addressing modes, but you should always be able to detect overflow in signed 2s complement addition by checking to see if both addends are positive and the result is negative. There is a similar check for subtraction.
    - chrisseaton 4y ago
      Yeah, but the point is addressing modes fuse addition and multiplication and using the result, so there's no opportunity to check anything after the operations.
  - mikewarot 4y ago
    That can't be true. Why would a compiler use memory access to do math? Math operations are register based, none of the quantities are addresses. How can you use memory addressing modes to do math, like 987*765?
    - chrisseaton 4y ago
      > That can't be true. Lol. See for yourself if you don't believe me. https://godbolt.org/z/o14f7cdsc https://godbolt.org/z/o14f7cdsc > Why would a compiler use memory access to do math? Because there are efficient instructions for it. Have you written an arithmetic code generation pass? It's normal to do it like this. > Math operations are register based, none of the quantities are addresses. An address is just a number. Yeah they're in registers or can be immediate. So what? > How can you use memory addressing modes to do math, like 987*765? Because AMD64 addressing modes have a base, a scale, and an offset component. That's multiplying and adding. Let me know how you think you can work out if that lea overflowed!
      - mikewarot 4y ago
        Wow, that's nuts. I'd have never expected that abuse. You can use -ftrapv to check for integer overflows, like this https://godbolt.org/z/snbdadv8b https://godbolt.org/z/snbdadv8b >Let me know how you think you can work out if that lea overflowed! LEA (Load Effective Address) can't overflow... memory is supposed to wrap, the byte after the last byte is byte 0.
        chrisseaton 4y ago
        Right but have you seen what that’s done to your machine code? That’s why people don’t do it normally. > LEA (Load Effective Address) can't overflow... You're mistaken - it's defined to overflow. https://reverseengineering.stackexchange.com/questions/11442/understanding-subtle-differences-between-addressing-modes-in-x86 https://reverseengineering.stackexchange.com/questions/11442...
        zorgmonkey 4y ago
        I'm not 100% sure, but I think that the behavior of LEA is to wrap, but it does not set the overflow flag
rep_lodsb 4y ago
The only modern architecture which does not have overflow detection is RISC-V.
- ama5322 4y ago
  Interesting. Is it a deliberate decision or just an omission?
  - snvzz 4y ago
    Deliberate. RISC-V architects weighted pros and cons of having a flags register, and pros and cons of having overflow exceptions. They concluded it is best to not have flags at all (conditional branches do their own testing, and no flag dependencies need to be tracked which simplify superscalar implementations) nor overflow checks (flow breaking and costly; if you need the check, the cost of a software check is minimal, by design).
    - renox 4y ago
      Minimal.. It depends! I remember that the developpers behind GMP (a GNU library for bignum) weren't happy with the performance! But that's pretty niche..
    - ama5322 4y ago
      I understand for overflow exceptions, but I would have expected the cost of a register flag to be zero or near zero, for example, in an integer adder? It also doesn't look like to me the cost of a software check can always be trivial. It can be for a single operation, but an advantage of an overflow register is that it allows to check for a group of operations as a whole (check/branch just once and abort), which is what is probably practical to do algorithmically. In such scenario switching to software checks for each op and/or bound check the inputs sounds by far not minimal.
      - snvzz 4y ago
        Flags aren't that simple. In a superscalar microarchitecture, then you have a lot more to track re: who set the flag, as the flag is a target of every instruction that can set it.

That's hardware specific, right? You're not guaranteed to have a solution on every platform.

mikequinlan 4y ago

All platforms can detect overflow in one way or another; for example by checking for an unexpected sign change.

chrisseaton 4y ago
AMD64 addressing modes cannot detect overflow, and this is where in practice 90% of arithmetic is done!
- mikequinlan 4y ago
  I don't know specific AMD64 addressing modes, but you should always be able to detect overflow in signed 2s complement addition by checking to see if both addends are positive and the result is negative. There is a similar check for subtraction.
  - chrisseaton 4y ago
    Yeah, but the point is addressing modes fuse addition and multiplication and using the result, so there's no opportunity to check anything after the operations.
- mikewarot 4y ago
  That can't be true. Why would a compiler use memory access to do math? Math operations are register based, none of the quantities are addresses. How can you use memory addressing modes to do math, like 987*765?
  - chrisseaton 4y ago
    > That can't be true. Lol. See for yourself if you don't believe me. https://godbolt.org/z/o14f7cdsc https://godbolt.org/z/o14f7cdsc > Why would a compiler use memory access to do math? Because there are efficient instructions for it. Have you written an arithmetic code generation pass? It's normal to do it like this. > Math operations are register based, none of the quantities are addresses. An address is just a number. Yeah they're in registers or can be immediate. So what? > How can you use memory addressing modes to do math, like 987*765? Because AMD64 addressing modes have a base, a scale, and an offset component. That's multiplying and adding. Let me know how you think you can work out if that lea overflowed!
    - mikewarot 4y ago
      Wow, that's nuts. I'd have never expected that abuse. You can use -ftrapv to check for integer overflows, like this https://godbolt.org/z/snbdadv8b https://godbolt.org/z/snbdadv8b >Let me know how you think you can work out if that lea overflowed! LEA (Load Effective Address) can't overflow... memory is supposed to wrap, the byte after the last byte is byte 0.
      - chrisseaton 4y ago
        Right but have you seen what that’s done to your machine code? That’s why people don’t do it normally. > LEA (Load Effective Address) can't overflow... You're mistaken - it's defined to overflow. https://reverseengineering.stackexchange.com/questions/11442/understanding-subtle-differences-between-addressing-modes-in-x86 https://reverseengineering.stackexchange.com/questions/11442...
      - zorgmonkey 4y ago
        I'm not 100% sure, but I think that the behavior of LEA is to wrap, but it does not set the overflow flag

rep_lodsb 4y ago

The only modern architecture which does not have overflow detection is RISC-V.

ama5322 4y ago
Interesting. Is it a deliberate decision or just an omission?
- snvzz 4y ago
  Deliberate. RISC-V architects weighted pros and cons of having a flags register, and pros and cons of having overflow exceptions. They concluded it is best to not have flags at all (conditional branches do their own testing, and no flag dependencies need to be tracked which simplify superscalar implementations) nor overflow checks (flow breaking and costly; if you need the check, the cost of a software check is minimal, by design).
  - renox 4y ago
    Minimal.. It depends! I remember that the developpers behind GMP (a GNU library for bignum) weren't happy with the performance! But that's pretty niche..
  - ama5322 4y ago
    I understand for overflow exceptions, but I would have expected the cost of a register flag to be zero or near zero, for example, in an integer adder? It also doesn't look like to me the cost of a software check can always be trivial. It can be for a single operation, but an advantage of an overflow register is that it allows to check for a group of operations as a whole (check/branch just once and abort), which is what is probably practical to do algorithmically. In such scenario switching to software checks for each op and/or bound check the inputs sounds by far not minimal.
    - snvzz 4y ago
      Flags aren't that simple. In a superscalar microarchitecture, then you have a lot more to track re: who set the flag, as the flag is a target of every instruction that can set it.