I've followed the discussion regarding how ASM should be integrated in Rust over the past few years, the idea of integrating the ASM syntax more tightly with Rust has been brought up. Basically one could treat assembly as an ad-hoc domain specific language with its own parsing rules that would make it more like a first class citizen instead of a magical character string. I've actually implemented a very simplistic MIPS assembler in a similar way for emulation purposes: https://github.com/simias/rustation/blob/master/src/parallel...

I think they were absolutely right not to go down that route, because then you have to basically specify this syntax for every possible architecture targeted by Rust. Integrating ASM in the language syntax is fine if you only care about x86, but it's going to be a mess if you want to support MIPS, ARM32, AARCH64, Sparc and whatnot because the ASM dialects for each of these architectures have special bespoke syntax to deal with various quirks of the underlying ISA. MIPS has special syntax to load the top and bottom half of an address as well as dealing with delay slots (.noreorder), ARM has special sugar for PC-relative addressing etc...

Importing that baggage into Rust would be a fool's errand IMO. It would also make it harder both to port Rust to new architectures and to transfer existing assembly code into Rust since it would require adjusting the syntax.

I'm very happy with Rust's current approach, it's a good middle ground IMO.

Is the MSVC dialect of C/C++ on x86-64 not a "PC based language"? Because it doesn't support inline asm at all.

Better not supporting it and just use external Assemblers or intrisics, like it does by shipping MASM in the box, a very good Macro Assembler, at least none of them are glueing strings together.

Also that same compiler still does it for x86.

what are PC based languages ? what is PC short for in this context

MS-DOS/Windows heritage.

Modula-2, Pascal, C, C++, Basic based compilers with inline Assembly parsers or intrisics that interact with host language type system instead of manually dealing with strings UNIX style.

But in rust asm! does interact with the type system.

The asm macro does know about what group of registers (or what specific register) a input/output is stored/loaded from and compilation will fail if the input isn't compatible with the register.

Then it's delegating to a assembler for the rest.

Sure it could also have a list of all asm commands the given target does support and parameters/registers it can be used with but this means keeping track of all supported targets and all commands for all potential featuresets of all targets and all way they can be called. This is a lot of work. Even more such support can be added later one, too. For now it's more important to support asm on stable.

Also with proc-macros you can implement this as a library on top of `asm`!

Also with a more "knowledgeable" asm any support for a new platform would need to manually add support for all asm of that language so having a standard stringly interface is a good think anyway.

What you describe is how it works in GCC/LLVM and is required in any inline asm system. Otherwise it is not really inline.

Saying that fits with the type system is a stretch... it is like any other FFI.

The use of strings in Rust's implementation is limited to the assembly template and the operand constraints. Functionally speaking, moving those out of strings gains you absolutely nothing and can make parsing more difficult.

The important part, type system integration, is already there. Sizes must match, move and borrow checking still happens, etc. This avoids the typical failure modes of unix-like stringly-typed systems. In fact if you read the announcement and RFC, you'll see that this was a primary goal of the new design!

Second that. Very simple example:

  function MultiplyBy2Reg(aInput: int64): int64 assembler 
  register;
  asm
    SHL RAX, 1;
  end;

  function MultiplyBy2(aInput: int64): int64 assembler;
  asm
    mov RAX, aInput;
    SHL RAX, 1;
  end;

Now I need to port that code to MIPS, what do?

This is a very nice feature to have if you know your environment is overwhelmingly tied to a certain architecture and you want to make it easy to target this architecture in particular.

This might actually be a somewhat reasonable, if short-sighted approach if we were in 2005 and you could make the point that anything that's not x86 is effectively legacy or niche but nowadays you need to at the very least support x86-64, ARM32 and AARCH64. Baking all these flavors of assembly into a language would be very heavy handed and a maintenance nightmare.

Beyond that we're not in the 90's anymore, ASM is not routinely used outside of very low level code these days. Even for performance people often opt for intrinsics instead. Compilers got massively better at optimizing code while humans got worse due to ever more complex architectures.

Being able to seamlessly blend ASM with normal code isn't that much of a killer feature anymore IMO. It would be a costly gimmick to implement.

It is Assembly after all, just use conditional compilation.

ifdef is your friend. used everywhere