145 karma · joined August 16, 2019
For many users of GCC the intended user base will be “the same as my current distribution” and so GCC can be configured using —-with-{cpu, arch, schedule, tune} depending on the architecture to set a default in line with user/distro expectations.
The other prompt that felt interesting to me was that you feel an intellectual limitation in terms of what you retain, what does that look like in practice?
But, I find the implication hard to accept.
It would be to say that Stallman’s continuing presence is essential to the success of free software; surely a frightening responsibility for any one mortal person to carry through their remaining years!
Free software has had success as a movement. To believe otherwise is to take away more than just Stallman’s position, but his entire contribution to our modern society!
That means there are others who will, and for a fact do already, take care for the well-being of the GNU projects. Not all of these will believe in everything Stallman has said or represents, and things would certainly change without him.
A large and successful movement lives beyond its founder, and grows to challenge the new status quo. If it fails to grow, new movements fill the vacuum.
If the latter, it doesn’t hurt my argument for you to pretend I never used the word forward at all, and I’m very happy for you to do so. Our common ground here is that things feel as though they are changing.
Many great leaders are as much a product of their time and circumstances as they are a reflection of their innate talents. Whether you see the world progressing or regressing you might still agree that Stallman is not necessarily effective in the current climate.
They have always been! You could at least have the dignity to read Stallman’s writings (a fine start is available at: https://www.gnu.org/philosophy/essays-and-articles.html , a more advanced diet is available at Stallman.org ) to understand just how politically charged GNU, the FSF, and Stallman have always been.
So now some members of a social movement disagree with the leader of that social movement you feel upset to see social issues discussed? That seems dishonest.
Why should any social and political movement remain beholden to one original star of the old guard as the world moves forward.
How ought the community respond to a trend to controversy and irrelevance other than by asking Stallman to step aside from the figurehead role? Is the argument here really that once you are a figurehead for a social movement you earn that position for life? I can’t think of any successful movement or organisation for which that has been the case.
GNU has always been political, the politics needed to bring software freedom to all users is different now than it was in the 90’s. Some battles have been won, others have been lost hard, new battles have arisen. An honest discussion of whether Stallman is best placed to lead those new battles is overdue.
Given that the FSF asks for donations for technical projects, and explicitly defines itself as a political organisation; the political opinions of its President would seem very relevant, valuable, and useful to discuss.
It may change how people choose to support free and open source software in future.
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 the sequential consistent model than it will for acquire/release.
The other is that there are two ways to provide atomics on Arm, and which you have access to depends on the architecture revision implemented by your particular Arm hardware. If you have Armv8.1-A atomic operations available to you, you’ll use a similar interface to x86; a single instruction which looks like a cmpxchg. If you don’t have the atomic extension, you’ll instead be using a load-lock/store-conditional loop of ldrex/strex for all of your atomic operations.
Getting this exactly right is tricky, so where possible I’d encourage using the atomic builtins (or, of course, your language’s portable API, over assembly).
The biggest benefit is that if in future architecture technology moves forward again, the GCC and language built ins will let you move with it, while assembly leaves you relearning occasionally.
Depending on who you ask, this is a feature, not a defect. Inline assembly is your last line of defence against a compiler which thinks it knows better than you.
Clang/llvm go a step further and do parse and optimize your inline assembly; that makes me uncomfortable, but I’ve always subscribed to the “don’t touch user asm” mindset for compiler development.
Your main benefit of builtins over assembly is that no matter how hard I tried I couldn’t get the suggested replacement given by the parent for __atomic_compare_exchange to assemble on my arm64 server!