4 ms·

There are many things that are present in assembly but lacking in C. For example, how do you detect integer overflow in C without resorting to compiler extensio

There are many things that are present in assembly but lacking in C. For example, how do you detect integer overflow in C without resorting to compiler extensions?

jjnoakes 10y ago
You stub out the few architecture specific routines you need and let someone write them for their architecture in asm if it doesn't exist already. A minimal porting effort for the best of all worlds.
- pcwalton 10y ago
  The best of all worlds, except that you lose your optimizations.
  - jjnoakes 10y ago
    I would like to see the benchmarks before I agreed to that. You might not get the best optimization possible if you have to leave it up to the C compiler with inline assember... But that mix worked well for C and C++. And rust can still optimize things like deciding which integer optimizations need the overflow check, and only add it where static analysis failed.
    - pcwalton 10y ago
      No, it doesn't work well for C and C++ at all. Turn off InstCombine and see what performance you get in LLVM for an idea of what will happen if the compiler doesn't know about the semantics of + and -.
      - jjnoakes 10y ago
        We are only talking about a subset of additions and subtractions to begin with. How often will idiomatic rust code need overflow checks? Also, if the UB operations are defined by target assembler (instead of in C++) then you may not even need extra overflow checks, depending on the assembler semantics. This would only be needed in the places where static analysis failed, of course. One could also use the native compiler options, if available, to avoid the issue alltogether (like -fwrapv).
        pcwalton 10y ago
        > We are only talking about a subset of additions and subtractions to begin with. No, you're talking about all signed addition. > How often will idiomatic rust code need overflow checks? You'd be surprised. Go look at the implementations of containers in the standard library. > Also, if the UB operations are defined by target assembler (instead of in C++) then you may not even need extra overflow checks, depending on the assembler semantics. This would only be needed in the places where static analysis failed, of course. I don't know what this means exactly. If you're saying you should implement a static analysis to try to eliminate unneeded overflow checks, then this is a huge burden. > One could also use the native compiler options, if available, to avoid the issue alltogether (like -fwrapv). If you're dependent on GCC/clang extensions to C, then you're not compiling to C. You're compiling to a front end to GIMPLE/LLVM. At that point there's no benefit over just compiling to GIMPLE or LLVM in the first place.
        jjnoakes 10y ago
        > No, you're talking about all signed addition. No, I'm talking about the ones that won't overflow. Some can be statically shown to not need a runtime check. > If you're dependent on GCC/clang extensions to C, then you're not compiling to C. I'm not saying that. I'm saying require either the target compiler (which the user is in control of) to provide a flag to give signed overflow the proper semantics (which would be useful if the user happens to be using clang or gcc), or fall back to requiring some asm for the target system which provides the needed semantics. This would all be up to someone to configure for the target machine. Not a big deal once per architecture. > At that point there's no benefit over just compiling to GIMPLE or LLVM in the first place. Well if GIMPLE or LLVM was available for all of the targets that C compilers are, then I'd agree. But they aren't. So I don't.
astrange 10y ago
I think these extensions: https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins... could be implemented in plain C if you're careful. It's not like the other extensions like __builtin_constant_p or asm that'd leave you stuck with GNU C. And besides, GNU C is good enough for lots of people!
- pcwalton 10y ago
  A lot of the claimed benefits of compiling to C--compilation to embedded targets without a GCC backend, most importantly--evaporate if you only compile to GCC's dialect of C. It's another way in which compiling to C ends up worse in the long run.

There are many things that are present in assembly but lacking in C. For example, how do you detect integer overflow in C without resorting to compiler extensions?

jjnoakes 10y ago

You stub out the few architecture specific routines you need and let someone write them for their architecture in asm if it doesn't exist already. A minimal porting effort for the best of all worlds.

pcwalton 10y ago
The best of all worlds, except that you lose your optimizations.
- jjnoakes 10y ago
  I would like to see the benchmarks before I agreed to that. You might not get the best optimization possible if you have to leave it up to the C compiler with inline assember... But that mix worked well for C and C++. And rust can still optimize things like deciding which integer optimizations need the overflow check, and only add it where static analysis failed.
  - pcwalton 10y ago
    No, it doesn't work well for C and C++ at all. Turn off InstCombine and see what performance you get in LLVM for an idea of what will happen if the compiler doesn't know about the semantics of + and -.
    - jjnoakes 10y ago
      We are only talking about a subset of additions and subtractions to begin with. How often will idiomatic rust code need overflow checks? Also, if the UB operations are defined by target assembler (instead of in C++) then you may not even need extra overflow checks, depending on the assembler semantics. This would only be needed in the places where static analysis failed, of course. One could also use the native compiler options, if available, to avoid the issue alltogether (like -fwrapv).
      - pcwalton 10y ago
        > We are only talking about a subset of additions and subtractions to begin with. No, you're talking about all signed addition. > How often will idiomatic rust code need overflow checks? You'd be surprised. Go look at the implementations of containers in the standard library. > Also, if the UB operations are defined by target assembler (instead of in C++) then you may not even need extra overflow checks, depending on the assembler semantics. This would only be needed in the places where static analysis failed, of course. I don't know what this means exactly. If you're saying you should implement a static analysis to try to eliminate unneeded overflow checks, then this is a huge burden. > One could also use the native compiler options, if available, to avoid the issue alltogether (like -fwrapv). If you're dependent on GCC/clang extensions to C, then you're not compiling to C. You're compiling to a front end to GIMPLE/LLVM. At that point there's no benefit over just compiling to GIMPLE or LLVM in the first place.
        jjnoakes 10y ago
        > No, you're talking about all signed addition. No, I'm talking about the ones that won't overflow. Some can be statically shown to not need a runtime check. > If you're dependent on GCC/clang extensions to C, then you're not compiling to C. I'm not saying that. I'm saying require either the target compiler (which the user is in control of) to provide a flag to give signed overflow the proper semantics (which would be useful if the user happens to be using clang or gcc), or fall back to requiring some asm for the target system which provides the needed semantics. This would all be up to someone to configure for the target machine. Not a big deal once per architecture. > At that point there's no benefit over just compiling to GIMPLE or LLVM in the first place. Well if GIMPLE or LLVM was available for all of the targets that C compilers are, then I'd agree. But they aren't. So I don't.

astrange 10y ago

I think these extensions: https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins... could be implemented in plain C if you're careful. It's not like the other extensions like __builtin_constant_p or asm that'd leave you stuck with GNU C. And besides, GNU C is good enough for lots of people!

pcwalton 10y ago
A lot of the claimed benefits of compiling to C--compilation to embedded targets without a GCC backend, most importantly--evaporate if you only compile to GCC's dialect of C. It's another way in which compiling to C ends up worse in the long run.