3 ms·
My problem with GCC has been that it is sorely lacking in optimizations for a lot of architectures. The particular example I'm thinking of is handling GPIO. In
by mystified5016 2y ago
My problem with GCC has been that it is sorely lacking in optimizations for a lot of architectures. The particular example I'm thinking of is handling GPIO. In most (all?) architectures, there's a clean way to get single-cycle access to IO, but GCC seems to like using the stupid method which takes 3-5 cycles.
I had to manually massage the C to get efficient assembly. At least GCC understands and respects when you manually write directly to a register. It gets turned into the correct single-cycle instructions.
There's other examples as well, in some architectures you can significantly speed up access to memory by storing a pointer in a special register. GCC just... doesn't. You have to do some nasty tricks with inline assembly and you have to just hope GCC doesn't stomp on that register anyway.
I've heard that clang is supposed to be better in this department, but I haven't felt like burning a couple of days to get it set up.
If I'm working on something that needs to go as fast as possible, I just keep the assembly pulled up all the time. CLion has this integrated and will link each line of C to the corresponding assembly section. It's been a massive help when micro-optimizing.
- Joel_Mckay 2y agoFor embedded, most of the magic happens in the linker, and proprietary binary image optimizer. Thus, indeed one must still declare some things as "volatile" to get repeatable behavior from some compilers. Notably, some vendors will provide asic optimized standard/DSP libraries for each chip, and this blob is linked into your code. Note, the real fun happens when small firms implement something like math.h sin() incorrectly. =) Adding layers of abstraction does not often make the problems easier, or safer to handle. However, we all find our own workflows, and if the product is stable for a year... everyone is happy. =3