4 ms·

What I want is for the semantics of the language to match the semantics of the physical machine I'm writing software for. If on x86 INT_MAX+1==INT_MIN, then tha

by anon4 11y ago

What I want is for the semantics of the language to match the semantics of the physical machine I'm writing software for. If on x86 INT_MAX+1==INT_MIN, then that's what should happen on x86. If on ARM INT_MAX+1==INT_MAX, that's what should happen on ARM. No, I don't want portability. Portability means you're coding against the least common denominator. If I want it to be portable, I'll use a different compiler.

zAy0LfpBZLC8mAC 11y ago
> If on x86 INT_MAX+1==INT_MIN [...] There is no such thing as "+ on x86". "+" is an operator of the C language. Modern x86 has about two dozen instructions that can be used to perform additions, each with slightly different behaviour, and with different performance characteristics. Someone has to define how C's "+" maps to those instructions. That is what the C standard does. The way it does that is by specifying properties that any implementation of C's "+" needs to have, leaving the specific choice of instructions to the compiler writer.
- Dylan16807 11y ago
  There are integer additions of different size, but is there anything you could honestly call plain integer addition that has different behavior from wrapping?
  - zAy0LfpBZLC8mAC 11y ago
    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. But the C standard doesn't say "+ maps to what you could honestly call plain integer addition" anyway, so it's kindof pointless? And if you were to define your own language, you obviously could define "+" to have architecture-specific semantics, whithout appealing to any "plain integer addition".
    - Dylan16807 11y ago
      >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. I'm not defining it that way. I used the word 'plain' because some instructions are specifically designed to be variants of normal instructions. It's in their name that they do thing abnormally, so they should be discarded when talking about normal behavior. >But the C standard doesn't say "+ maps to what you could honestly call plain integer addition" anyway, so it's kindof pointless? You originally said: There is no such thing as "+ on x86". "+" is an operator of the C language. So I was explaining what "+" means in the absence of C rules. + 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. And I already explained why I used the word 'plain'. - 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? If there are none, then I am comfortable asserting that "+" on x86 exists and is twos-complement.
      - zAy0LfpBZLC8mAC 11y ago
        > + 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

by anon4 11y ago

zAy0LfpBZLC8mAC 11y ago

> If on x86 INT_MAX+1==INT_MIN [...] There is no such thing as "+ on x86". "+" is an operator of the C language. Modern x86 has about two dozen instructions that can be used to perform additions, each with slightly different behaviour, and with different performance characteristics. Someone has to define how C's "+" maps to those instructions. That is what the C standard does. The way it does that is by specifying properties that any implementation of C's "+" needs to have, leaving the specific choice of instructions to the compiler writer.

Dylan16807 11y ago
There are integer additions of different size, but is there anything you could honestly call plain integer addition that has different behavior from wrapping?
- zAy0LfpBZLC8mAC 11y ago
  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. But the C standard doesn't say "+ maps to what you could honestly call plain integer addition" anyway, so it's kindof pointless? And if you were to define your own language, you obviously could define "+" to have architecture-specific semantics, whithout appealing to any "plain integer addition".
  - Dylan16807 11y ago
    >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. I'm not defining it that way. I used the word 'plain' because some instructions are specifically designed to be variants of normal instructions. It's in their name that they do thing abnormally, so they should be discarded when talking about normal behavior. >But the C standard doesn't say "+ maps to what you could honestly call plain integer addition" anyway, so it's kindof pointless? You originally said: There is no such thing as "+ on x86". "+" is an operator of the C language. So I was explaining what "+" means in the absence of C rules. + 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. And I already explained why I used the word 'plain'. - 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? If there are none, then I am comfortable asserting that "+" on x86 exists and is twos-complement.
    - zAy0LfpBZLC8mAC 11y ago
      > + 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