Compilers are programmed by humans. You are claiming that somehow compilers have learned to produce better assembly than the humans that programmed them.
I am a compiler writer, and know many compiler writers. I have yet to find one that would stand by your claim. When I look at the output of LLVM or GCC, I am ashamed.
I wish I had more time to make LLVM much better, but actually, 99% of my time is spent in fixing bugs filled by users that are neither compiler writers nor assembly programmers, and they too realized how bad the machine code emitted by these tools is.
So sure, a compiler emits better assembly than a human that hasn't learn assembly programming. It also emits better assembly than all humans that do not know how to program.
But no, it does not produce _by far_ better assembly than any programmer that actually cares about machine code enough to just take a look at it and check it.
The problem is not whether its bad or not, but rather, having to learn a completely-different second syntax for one architecture.
Most Rust code is quite portable, targeting ARM, x86, MIPS, PPC, WASM, Sparc, s390x, riscv, ... That means, that for many snippets of inline assembly, you might encounter ~8 of them, one for each architecture, all using different syntaxes.
Intel syntax is quite similar to that of other popular architectures `op dst, args...`.
Adding another second syntax for x86 just doesn't add that much value IMO, and adds quite a bit of cost: now everybody dealing with x86 assembly needs to learn 2 syntaxes... and everybody dealing with portable code now needs to be at least able to read 2 syntaxes for x86... Without talking about the cost of implementing a second syntax in the compiler, etc.
If you prefer AT&T, you can always write a proc macro that translates it to Intel, and use that in your projects.
If I ever need to deal with such code, I'd just expand the macro to read the actual Intel syntax, modify that, and either fork the project, or submit a patch with a fix using Intel syntax.
Notice that you can quite easily implement a Rust proc macro that takes whatever DSL you want to use for inline assembly, and generates an `asm!` expression from it.
So better syntaxes are possible, as long as they can be built on top of the proposed inline-assembly feature.
They can, however, just be implemented as normal Rust libraries, and do not need to be part of the compiler.
Shipping LLVM bitcode is mandatory for the AppStore, Apple can then compile that bitcode to binaries for different hardware.
That's why if you are shipping code to the AppStore, you probably don't really care whether Apple uses x86, ARM, RiscV, powerpc, or all of them in different devices. Producing working binaries becomes Apple's job.
Browsers are quite good at this actually. Major web browsers run on Windows (and even 32-bit windows!), where there is no overcommit, so malloc can return "no" any time, which happens quite often when you are limited to 4Gb of memory per process.
The only apps that suck at this are Linux-only apps that are never used anywhere else and just assume that all Linux systems have overcommit enabled.
> > The way to mark priority in killing is to adjust this score through /proc.
>
> Haven't heard about this, thanks for the heads up!
While going down that road is technically correct, it is a road full of pain.
A slightly less painful strategy is to disable overcommit. That way, if memory pressure is high, and a process calls `malloc`, that call will fail if there is not enough memory, and that process will fail. If you only have a couple of processes in your system that are using most of the memory and you can control them, it is simpler to just making them resilient to these kind of errors, than to try to mess with the process score to control the OOM killer.
I take the train in a big German city every day. If my train were to arrive on time one day, I would share that information with all my friends as something more than exceptional. This never happens. I can't wait till i've saved enough to buy a car and stop using the trains and subway.
Compilers are programmed by humans. You are claiming that somehow compilers have learned to produce better assembly than the humans that programmed them.
I am a compiler writer, and know many compiler writers. I have yet to find one that would stand by your claim. When I look at the output of LLVM or GCC, I am ashamed.
I wish I had more time to make LLVM much better, but actually, 99% of my time is spent in fixing bugs filled by users that are neither compiler writers nor assembly programmers, and they too realized how bad the machine code emitted by these tools is.
So sure, a compiler emits better assembly than a human that hasn't learn assembly programming. It also emits better assembly than all humans that do not know how to program.
But no, it does not produce _by far_ better assembly than any programmer that actually cares about machine code enough to just take a look at it and check it.