Richer inline asm

compiler
1

So... will we ever get better inline assembly? Rust's current core::arch::{asm, global_asm} (hereinafter: asm) are really good and rust's inline assembly is one of the best of all languages (convenient syntax switch, argument passing, etc.) but it is not perfect. Asm's syntax in Rust is Intel by default, which cannot but rejoice, but it still looks like GAS. Probably, many people like GAS but it is too abstract for being an assembler. So, my offer is too add nasm/fasm-like syntax to asm (without deprecating gas-like). I mean to allow using less-abstract things like db instead of different kinds of pseudo-types (.ascii, for example). Also can't we join global and inline asm into one macro (I've heard about statement/global macros, but...) or add an additional operator for this purpose?

I know the theme is controversial, please don't throw slppers at me...

2

I guess you can do that as a procedural macro library, no need to change the language.

3

While this would be nice, it's not really possible, because they have different semantics. In Rust, you can include items in what is traditionally "statement position"

eg 
fn example() {
    struct S;
}

so the fact that global_asm! is forbidden in "statement item position" is effectively just a safeguard against mixing up asm! and global_asm!, because it would have fully predictable semantics. Making asm! infer that it should behave as global_asm! in "item position" (and as asm! in "statement position") breaks this property of all items being valid in "statement position" as an "item statement".

Ultimately, asm! is implemented by lowering to LLVM assembly items. (There is a defined semantic for how to implement asm! with an external assembler and linking it in, but in practice for halfway decentish codegen around asm!, LLVM assembly needs to be used.) Rust really does not want to be in the business of interpreting the contents of the assembly template, so what's valid assembly is up to the backend assembler. The main nicety is in automatically enabling GAS and Intel modes by default.

If LLVM supports nasm directives, then I would suspect adding an options(nasm_directives) flag would be non-controversial.

4

@CAD97, you're right but unfortunately only words very rarely change the stuff's progress.

@Uther, probably, this is a good idea, I'll try to do something.

5

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.