Nobody's proposing your code for the C standard. The original article is proposing an addition to the standard. Your comment argues that programmers don't need the addition to the standard because there is a non-standard, non-portable hack. That is not a good argument against an addition to the standard.
The onus is on the proposer. C is simple and should stay that way. If someone is proposing C needs to be altered (which is about the most conservative language there is when it comes to adopting features) then that person should have good arguments as to why there's no other way. Otherwise it belongs in C++. If whipping up a few lines of asm for my local architecture solves the problem, then that weakens the proposal.
Rust asm syntax looks nice, but the syntax is just the tip of the iceberg. asm() is almost a misnomer. Its true power is the constraints system that lets us control GCC/Clang internal algorithms. You may have noticed that the defer() macro uses asm() with an empty string!
It's such a general tool that's become so prevalent as a practice (since Stallman invented it in the early 90's) that I would surely hope it's on the radar of language committees by now. If these definitions and mnemonics can be formalized or at least clarified by standards bodies, then they should be.
I think your implementation is really, really cool. Similarly I spent a good half hour bumbling through Cosmopolitan. Love what you've built.
IMO, the fact that asm() is used for a bunch of things unrelated to inline assembly -- but to your point, instead for changing compiler behaviors is more of an argument for exposing additional __attributes__, annotations and so on, rather than adding explicit support for asm() to the standard. This violates the principal of least surprise, and IMO, serves to further confuse rather than bring some predictability to C.
I'd suggest also that C should embrace some movement in the standard rather than agreeing to leave things as is forever and stapling legs onto the octopus that is C++. There was a good writeup here a while ago from someone involved with the committee, that they've gotten to the point where introducing new warnings for obviously broken behavior is off the table because they want to be warnings-compatible from release to release.
What I'm saying is I would rather see exposed intrinsics, primitives and other meaningful source annotations than codifying the spooky action at a distance of an empty string asm() call in the C standard. And if we're going to modify the standard there's a lot of low-hanging fruit I'd love to see cleaned up first.
[edit] I'd also like to add that I agree with your thesis that if this can be built with the tools provided instead of modifying the standard, that the onus is on the proposer. Based on some of the other analyses here it seems like it can't really be done in a universal way, but I'm open minded.
Hmm, that’s actually a very interesting viewpoint on inline assembly, and it’s certainly something that I think may be useful to have. That being said, the ergonomics of actually using it are still kind of poor, even putting aside the strange register names and such, since it’s obviously not really designed to do this. And the other concern I would have is that compilers tend to be fairly conservative when seeing such constructs; I think even with operands specified as much as possible there are still substantial gaps in what you can express to the compiler and also how much the compiler actually cares that you marked a particular register set as being clobbered-it might just spill more or be conservative if it doesn’t want to deal with your constraints. I should probably look to see if compilers treat it better today.
You're not alone in feeling that way. There's a very short list of people who've ever taken the time to fully grok Richard Stallman's Math 55 assembly notation, and they mostly work on projects like the Linux Kernel and glibc. It's designed to do anything. I've been using it the past few days to retool the standard x86_64 compiler to generate 16-bit boot code for The LISP Challenge. https://github.com/jart/cosmopolitan/blob/b6793d42d5ed6b4f78...
