5 ms·

Neither of those two compile down to what I imagine would be the best on x86, namely an add and then a check of the overflow flag. Is there any portable versio

Neither of those two compile down to what I imagine would be the best on x86, namely an add and then a check of the overflow flag. Is there any portable version that compiles down to that on GCC or Clang on x86?

acqq 12y ago
Once you have a function consistently used in your code the portable version can be used for the targets for which you don't provide an asm implementation, and the asm (or the solution customized to the compiler) can be selected implementation otherwise, covering the most common processors of today.
- Someone 12y ago
  Alternatively, bug the compiler writers to make their compiler recognise that portable version. That way, you don't have to maintain all those special code paths. Getting the compiler writers to help you is easier if your project is significant, or if you use a portable version that a big open source project uses.
  - acqq 12y ago
    My proposal costs the implementer just a few #if lines in one file. Your alternative costs much more people much more time, and the gain is then just... the implementer saves a few #ifs.
    - TheLoneWolfling 12y ago
      By that logic most HLLs shouldn't have been made. Remember - write once run many times. Implementing it in GCC / etc once means that many people won't have to do it themselves - especially as it's far more likely that one implementation will be bug-free than many people writing their own.
      - acqq 12y ago
        It's not the feature that anybody would use as is, when you'd use it you'd prefer to call the function. But then what's behind the function is irrelevant for the users of the function. We don't force compiler authors to put in the compiler what can be nicely put in the libraries. It's: write one header with a few #if's once, everybody use it, whenever she needs it. You'd just call is_safe_to_add_ints( s, t[i] ) and be sure that on the common platform it's optimal thanks to the #if's in the header, and not write bool bsafe = (t[i] < 0) ? s >= INT_MIN - t[i] : s <= INT_MAX - t[i]; every time you'd want to check if the addition would be safe.
        Someone 12y ago
        But you want if( !canSafelyAdd(a,b)) return ERROR; c = a + b; To compile down to an add and a check of the overflow bit. For that, you need help from the compiler. There are many examples where compilers special-case what is in a library. For example, compilers know they do not have to call strlen every time through this loop: for(int i = 0; i < strlen(s); ++i)
        acqq 12y ago
        The enough help you need is, in the implementation of the library function #if X86 #if GCC etc and then the assembly for each case, otherwise the slow but standard implementation. And that's one file, the code never to be directly used but by function name. It's already done this way in the current libraries for a lot processor specific stuff.

acqq 12y ago

Once you have a function consistently used in your code the portable version can be used for the targets for which you don't provide an asm implementation, and the asm (or the solution customized to the compiler) can be selected implementation otherwise, covering the most common processors of today.

Someone 12y ago
Alternatively, bug the compiler writers to make their compiler recognise that portable version. That way, you don't have to maintain all those special code paths. Getting the compiler writers to help you is easier if your project is significant, or if you use a portable version that a big open source project uses.
- acqq 12y ago
  My proposal costs the implementer just a few #if lines in one file. Your alternative costs much more people much more time, and the gain is then just... the implementer saves a few #ifs.
  - TheLoneWolfling 12y ago
    By that logic most HLLs shouldn't have been made. Remember - write once run many times. Implementing it in GCC / etc once means that many people won't have to do it themselves - especially as it's far more likely that one implementation will be bug-free than many people writing their own.
    - acqq 12y ago
      It's not the feature that anybody would use as is, when you'd use it you'd prefer to call the function. But then what's behind the function is irrelevant for the users of the function. We don't force compiler authors to put in the compiler what can be nicely put in the libraries. It's: write one header with a few #if's once, everybody use it, whenever she needs it. You'd just call is_safe_to_add_ints( s, t[i] ) and be sure that on the common platform it's optimal thanks to the #if's in the header, and not write bool bsafe = (t[i] < 0) ? s >= INT_MIN - t[i] : s <= INT_MAX - t[i]; every time you'd want to check if the addition would be safe.
      - Someone 12y ago
        But you want if( !canSafelyAdd(a,b)) return ERROR; c = a + b; To compile down to an add and a check of the overflow bit. For that, you need help from the compiler. There are many examples where compilers special-case what is in a library. For example, compilers know they do not have to call strlen every time through this loop: for(int i = 0; i < strlen(s); ++i)
        acqq 12y ago
        The enough help you need is, in the implementation of the library function #if X86 #if GCC etc and then the assembly for each case, otherwise the slow but standard implementation. And that's one file, the code never to be directly used but by function name. It's already done this way in the current libraries for a lot processor specific stuff.