It's not "PC based" that's the magic you want, it's the assumption of x86 (and, very recently, sorta, ARM, in a few compilers).
Architectures are weird, assembly is crazy. There just isn't going to be a single set of semantics around what you want.
This Rust thing isn't revolutionary, it's indeed just a prettier way of writing the model GCC invented a few decades back:
+ "Assembly" is a black box for the code author.
+ The compiler's job is generating code around the assembly, not the code itself.
+ So the fundamental model is "constraints": the rules the compiler needs to follow before and after the assembly, and how to emit an appropriate string to represent the register/address/immediate/whatever requested by the assembly code.
And like it or not, this works. It works really well. Generations of OSes have been written in this model without much complaint (beyond the general ugliness of the gcc syntax, which Rust is trying to fix).
I think this is fine. I agree it's not going to bring a revolution, but we really don't want one in this space.
I still think you're missing the point. GCC indeed didn't invent "inline assembly as a string", no.
GCC invented "constraint metalanguage as the foundation for inline assembly generation", which is the model here that enables one compiler and one syntax to work the same way for basically every architecture over decades. Modelling the interior of the assembly code as a black box (which in this implementation means "string") is just a side effect of this important design choice.
Again, the stuff you're imagining isn't a general purpose assembly language model, it's an x86-specific hack that works only on the specific compilers and architectures for which it was targeted.
Except that compilers with inline Assembly also don't have dumb backends that just dump Assembly for as, like on UNIX.
They interact with the backend.
They weren't specific of x86, although I mentioned only PC, they were available across all 8 and 16 bit home computers and several embedded targets support it as well.
GCC doesn't implement the "dumb approach" that existed before it, and that Amiga and Atari originally had. The GCC approach provides enough information to the compiler that code can be optimized in the presence of inline assembly; the compiler is informed of what the assembler code reads and writes, and can allocate registers for it. It was much more flexible than the implementation in the original Unix compiler.
Architectures are weird, assembly is crazy. There just isn't going to be a single set of semantics around what you want.
This Rust thing isn't revolutionary, it's indeed just a prettier way of writing the model GCC invented a few decades back:
+ "Assembly" is a black box for the code author.
+ The compiler's job is generating code around the assembly, not the code itself.
+ So the fundamental model is "constraints": the rules the compiler needs to follow before and after the assembly, and how to emit an appropriate string to represent the register/address/immediate/whatever requested by the assembly code.
And like it or not, this works. It works really well. Generations of OSes have been written in this model without much complaint (beyond the general ugliness of the gcc syntax, which Rust is trying to fix).
I think this is fine. I agree it's not going to bring a revolution, but we really don't want one in this space.