Sadly it is yet another language that follows the UNIX tradition of not having a proper Assembly parser instead forcing us to play with strings.
I guess it leaves PC based languages to have actual inline Assembly parsers or intrisics.
I guess it leaves PC based languages to have actual inline Assembly parsers or intrisics.
Don't get me wrong: Parsed assembly is superior because you can have certain parser guarantees/checks. But it will definitely limit the scope of your language or at least slow its adoption to new platforms.
That being said, it wouldn't be hard to create an asm_x86! macro that hides the string.
But related: There's no reason parsers cannot be externalized and inject the resultant assembly strings into the Rust solution. If that's really what people want. The nice thing about external parsers is that they become optional in every sense.
If the Rust team builds them in, then every supported platform needs support, every development environment needs every parser, and tooling also has to support it (e.g. IDEs, code checkers, etc).
It isn't simply just adding it once and leaving it forever, the work is repeated several times over and the maintenance will be time-consuming for what is: A niche feature.
Productivity matters everywhere, systems languages that care about happy programmers have better chances of long term adoption.
It also ignores the reality that the Rust team's time is finite, and if they invest it into three or more assembly parsers then they aren't investing it into other areas of the language that could also be productivity multipliers. Areas that more programmers actually use.
Ultimately how much is unsafe assembly in Rust going to be used? And how large are those code sections? And are you better off creating Assembly in existing dedicated tooling and importing it, even if Rust had native parsers (e.g. due to better debugging/visualization elsewhere)?
Honestly if Rust code outside of standard libraries ends up with a ton of assembly anyway then that's a weakness of Rust. You should be using as little as possible. Even unsafe Rust is superior to assembly because it is platform agnostic. I'd go as far as to call it a "last resort."
Niche is about the environment, i.e. the problem domain.
Analogy to biology/ecology, grazing on mountain tops is a niche that is also unpopular (i.e. low usage), meanwhile pollination is a niche that is popular.
The problem domain for Rust to be useful is very large, across the programming ecosystem and across the programming ecosystem effort is put into increase accessibility for the less and less experienced (e.g. embedded, wasm, webservers, clis, etc). However, Rust might currently lack popularity (i.e. low usage).
The problem domain for Inline Asm to be useful is very small, typically by experts in narrow domains and across the programming ecosystem effort is put into decrease the need for inline asm (e.g. crypto, firmware, drivers, etc). It also happens to be unpopular, and is avoided as much as possible.
Summary, Rust is pragmatically niche, rather than theoretically niche, Inline Asm is theoretically niche, and also pragmatically niche.
They are free to go elsewhere more welcoming.
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.
Amiga and Atari also had similar inline Assembly support.
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.
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.
If you want to use a single specific instruction or two, it's usually better to just use the compiler's intrinsics (Rust has already stabilized the x86 SSE and AVX intrinsics) than inline assembly. When you go to more complex assembly fragments, you tend to need more control over how the inline assembly fragment interacts with scheduling and the register allocator, and making that control work ergonomically is that much more challenging.
I can see why they would not want to bless a particular syntax tree or whatever into the core compiler.
On the rare occasion I write inline assembly, my annoyances were autoindent, syntax highlighting, and keystrokes required. Only the latter is directly caused by the stringy inline syntax, and an editor could still mitigate it.