3 ms·

> + means addition in general conversation, that's basic math and English skills. > > That it's integer addition is obvious from context, because we're adding 1

> + means addition in general conversation, that's basic math and English skills. > > That it's integer addition is obvious from context, because we're adding 1 to INT_MAX. Well ... yeah, "+" usually means addition, sure. But there are so many types of addition that that's not really specific enough for a language definition. And adding 1 to INT_MAX? Well, you could interpret "INT_MAX" to indicate C code, and thus "+" to be C's addition operator. In which case, it's not integer addition, at least not the kind that basic math and English skills would suggest: Adding two positive integers is always defined (and also never gives a value lower than either of the two operands), very much unlike "+" for "int"s in C. > There are architectures with normal integer add instructions that do not have twos-complement behavior. I'm just not aware of any such instructions on x86. Can you name one? Sure, PADDSW, for example. At least if I understand your "twos complement" requirement correctly to mean a specific wraparound behaviour. Or, if you want to count that, DAA and AAA.

Dylan16807 11y ago
>PADDSW As I see it that's a variant of PADDW, so whatever PADDW does is what matters, and PADDW does twos complement. >DAA and AAA I thought about calling those out, I think it's stretching too much to refer to an archaic instruction that works on 'ascii' or such when we're figuring the behavior of 'integers'. Even if it is one byte.
- zAy0LfpBZLC8mAC 11y ago
  > As I see it that's a variant of PADDW, so whatever PADDW does is what matters, and PADDW does twos complement. Nope, PADDW is a variant of PADDSW, so whatever PADDSW does is what matters, and PADDSW does saturating addition. Or in other words: You are defining "normal" to mean "twos-complement with wrap-around" after all, which makes it rather unsurprising that every "normal" instruction according to your definition turns out to be doing twos-complement addition with wrap-around. > I thought about calling those out, I think it's stretching too much to refer to an archaic instruction that works on 'ascii' or such when we're figuring the behavior of 'integers'. Even if it is one byte. Well, packed BCD definitely is not ASCII. Nor twos-complement, nor ones-complement, nor IEEE754. And BCD quite definitely represents a range of the integers.
  - Dylan16807 11y ago
    "ascii adjust after addition" > Nope, PADDW is a variant of PADDSW, so whatever PADDSW does is what matters, and PADDSW does saturating addition. That's like arguing that Red Sports Car is a variant of Red Sports Car with Stripes. The one that adds adjectives is the variant, the one without those adjectives is the base. If PADDW did saturating arithmetic and PADDWW did wrapping, I would agree with you, but that's not how x86 works.
    - ori_b 11y ago
      It is, however, what many DSPs do.
      - makomk 11y ago
        Many DSPs don't support byte addressing or arithmetic on 8-bit integers which a huge amount of non-DSP C code relies on. They're not exactly friendly to code not written specifically to run on the DSP. (Or C code in general, for that matter - the reason they have saturating addition and other oddball instructions is because it makes a lot of DSP code faster, but there's no C representation of any of those things.)
        ori_b 11y ago
        And now we get back to the initial quote: "What's your point? If you define a "plain integer addition" to be "wrapping binary two-complement addition", then there isn't, otherwise, there is."
        Dylan16807 11y ago
        Okay, well since it's my term, I'll make it absolutely clear. The definition is not circular. On those DSPs, plain integer addition is saturating. For x86, so far all evidence points to it being twos-complement. So the original original quote, "on x86 INT_MAX+1==INT_MIN", is true. As far as I can tell.

Dylan16807 11y ago

>PADDSW As I see it that's a variant of PADDW, so whatever PADDW does is what matters, and PADDW does twos complement. >DAA and AAA I thought about calling those out, I think it's stretching too much to refer to an archaic instruction that works on 'ascii' or such when we're figuring the behavior of 'integers'. Even if it is one byte.

zAy0LfpBZLC8mAC 11y ago
> As I see it that's a variant of PADDW, so whatever PADDW does is what matters, and PADDW does twos complement. Nope, PADDW is a variant of PADDSW, so whatever PADDSW does is what matters, and PADDSW does saturating addition. Or in other words: You are defining "normal" to mean "twos-complement with wrap-around" after all, which makes it rather unsurprising that every "normal" instruction according to your definition turns out to be doing twos-complement addition with wrap-around. > I thought about calling those out, I think it's stretching too much to refer to an archaic instruction that works on 'ascii' or such when we're figuring the behavior of 'integers'. Even if it is one byte. Well, packed BCD definitely is not ASCII. Nor twos-complement, nor ones-complement, nor IEEE754. And BCD quite definitely represents a range of the integers.
- Dylan16807 11y ago
  "ascii adjust after addition" > Nope, PADDW is a variant of PADDSW, so whatever PADDSW does is what matters, and PADDSW does saturating addition. That's like arguing that Red Sports Car is a variant of Red Sports Car with Stripes. The one that adds adjectives is the variant, the one without those adjectives is the base. If PADDW did saturating arithmetic and PADDWW did wrapping, I would agree with you, but that's not how x86 works.
  - ori_b 11y ago
    It is, however, what many DSPs do.
    - makomk 11y ago
      Many DSPs don't support byte addressing or arithmetic on 8-bit integers which a huge amount of non-DSP C code relies on. They're not exactly friendly to code not written specifically to run on the DSP. (Or C code in general, for that matter - the reason they have saturating addition and other oddball instructions is because it makes a lot of DSP code faster, but there's no C representation of any of those things.)
      - ori_b 11y ago
        And now we get back to the initial quote: "What's your point? If you define a "plain integer addition" to be "wrapping binary two-complement addition", then there isn't, otherwise, there is."
        Dylan16807 11y ago
        Okay, well since it's my term, I'll make it absolutely clear. The definition is not circular. On those DSPs, plain integer addition is saturating. For x86, so far all evidence points to it being twos-complement. So the original original quote, "on x86 INT_MAX+1==INT_MIN", is true. As far as I can tell.