It surprises me more of these haven't become standardised features. __builtin_expect is very common (but as a compiler hint I somewhat understand its absence), __builtin_clz is arguably a missing feature.
Understanding GCC Builtins to Develop Better Tools [pdf]
21–28 of 28 posts
Re: Understanding GCC Builtins to Develop Better Tools [pdf]
#22Earlier quoted context omitted.
I've never coded directly for ARM, but if it's anything like x86, then this example might help you (on GCC6+): char DidIt; asm("lock cmpxchg" : "=@ccz"(DidIt), "+m"(IfThing), "+a"(IsEqualToMe) : "r"(ReplaceItWithMe) : "cc");
Thank you for assuming the best from me, and providing a genuine attempt at help in response to my much more bad-faith remark. Two things complicate the AArch64 (Arm64) story for atomic builtins. One is Arm’s weak memory model. This permits different, more efficient, implementations of compare exchange depending on which of the C++ ordering guarantees you need and ask for. A compiler will generate different code for…
I think it's awesome that GCC provides builtins that help ARM devs generate the best atomic code possible, for ARM. As someone who only cares about her coding running natively on x86, I would obviously never use C/C++11 atomics, since it's kind of regressive for a high-level language to specify 42 different ways to say "MOV". How would I even know my code works? The way I see it, the "portability" here only flows in one direction: helping ARM/MIPS/etc. folks move to x86. The only thing I don't get, is why it's part of the language standard.
Re: Understanding GCC Builtins to Develop Better Tools [pdf]
#23It surprises me more of these haven't become standardised features. __builtin_expect is very common (but as a compiler hint I somewhat understand its absence), __builtin_clz is arguably a missing feature.
I suspect (but haven't verified) that modern compilers are actually implementing __builtin_expect() as a no-op. Much better alternatives exist today, e.g. GCC 8+ __cold__ and profile guided optimizations, which don't have a negative impact on code readability.
Re: Understanding GCC Builtins to Develop Better Tools [pdf]
#24Earlier quoted context omitted.
It's always funny when C people rediscover parts of C++. Yet they can never admit to it.
I write in C only when I need to; in my case I have a limited runtime environment available, so I can't use some other language (which I might otherwise prefer) with a larger runtime requirement, and I also already know C, but not C++. Also, none of the libraries I have to use have C++ APIs. Had I already known C++, and if there were C++ APIs available for the libraries I need, then sure, I might have used C++, but a…
C++ is perfectly able to interface and interact with C libraries. Also it doesn't necessarily produce larger or slower binaries. Virtually everything is optional. The only hard part about C++ is to identify the good parts (those that are useful for your project) and to not use the other parts. Then you can do "C with templates" or "C with simple classes that have proper RAII" but you don't need exceptions. The argument that I keep hearing is kind of the "slippery slope" that if one allows a little bit of C++ the rest will come creeping and with it will come all complexity. This shows that project management is weak and tries to deal with this weakness by selecting tools with limited capability. A method that seems to work reasonably well in cases like the Linux kernel.
Re: Understanding GCC Builtins to Develop Better Tools [pdf]
#25Earlier quoted context omitted.
I write in C only when I need to; in my case I have a limited runtime environment available, so I can't use some other language (which I might otherwise prefer) with a larger runtime requirement, and I also already know C, but not C++. Also, none of the libraries I have to use have C++ APIs. Had I already known C++, and if there were C++ APIs available for the libraries I need, then sure, I might have used C++, but a…
Learning C++ is easy. What's hard is being able to afford a computer that can compile it in a reasonable amount of time. I've seen projects written in C / Assembly that build over 9,000 objects in about 20 seconds on just one PC, whereas more than a few C++ codebases I've seen in the past couple years, that can be about as long as it takes to build just one file. I honestly suspect the only folks really writing C++ c…
Are there languages that have powerful template metaprogramming that are much faster to compile?
Re: Understanding GCC Builtins to Develop Better Tools [pdf]
#26Earlier quoted context omitted.
I write in C only when I need to; in my case I have a limited runtime environment available, so I can't use some other language (which I might otherwise prefer) with a larger runtime requirement, and I also already know C, but not C++. Also, none of the libraries I have to use have C++ APIs. Had I already known C++, and if there were C++ APIs available for the libraries I need, then sure, I might have used C++, but a…
C++ is perfectly able to interface and interact with C libraries. Also it doesn't necessarily produce larger or slower binaries. Virtually everything is optional. The only hard part about C++ is to identify the good parts (those that are useful for your project) and to not use the other parts. Then you can do "C with templates" or "C with simple classes that have proper RAII" but you don't need exceptions. The argume…
Unfortunately, for any human activity at scale, project management is weak. You can get good quality with small teams, but when more than 100 people are together, you can be sure that someone is going to commit every athrocity they can get away with. And then major damage happens, even if all the other people do aperfect job.
See Boeing recently. See chernobyl. See any major disaster.
So having tooling that limit your ability to do damage, even at the cost of pain for power users, is one of the few ways to keep humanity in check.
Re: Understanding GCC Builtins to Develop Better Tools [pdf]
#27Earlier quoted context omitted.
I write in C only when I need to; in my case I have a limited runtime environment available, so I can't use some other language (which I might otherwise prefer) with a larger runtime requirement, and I also already know C, but not C++. Also, none of the libraries I have to use have C++ APIs. Had I already known C++, and if there were C++ APIs available for the libraries I need, then sure, I might have used C++, but a…
C++ is perfectly able to interface and interact with C libraries. Also it doesn't necessarily produce larger or slower binaries. Virtually everything is optional. The only hard part about C++ is to identify the good parts (those that are useful for your project) and to not use the other parts. Then you can do "C with templates" or "C with simple classes that have proper RAII" but you don't need exceptions. The argume…
Unfortunately, in order to pick the good parts of C++ which are appropriate for your project, you first have to know all of C++.
Re: Understanding GCC Builtins to Develop Better Tools [pdf]
#28Earlier quoted context omitted.
Yes, the limited runtime is what is prohibiting me from using, say, Python. Runtime-wise, C++ would be fine. It’s the other reasons I listed which makes me not use C++ in this case.
Is C++ -> C interop your only reason for avoiding C++? If it is then you might reconsider C++, because calling C code from C++ is usually as easy as wrapping the #include in an extern "C" block.
I know it’s easy to call C functions from C++. That’s not the issue. The issue is that since all the API functions are in C, the code of my program will mold itself around those APIs, and my program will therefore have a C “shape”, so to speak. And the small pieces that remain C++-shaped might not be large enough or provide enough architectural benefit for the drawbacks of C++ to be worth it.