Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: refine the asm! extension #129

Closed
wants to merge 4 commits into from
Closed

Conversation

pczarn
Copy link

@pczarn pczarn commented Jun 18, 2014

Rendered view

An existing implementation: https://github.com/pczarn/code/blob/master/rust/asm/lib.rs

Some polishing of the implementation is necessary. It doesn't handle corner cases and incorrect input that well.

within the assembly string:

```rust
asm!("syscall" : "{rax}" = n -> ret, {rdi}" = a1, "{rsi}" = a2, "rcx", "r11", "memory", "volatile");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there an issue with your quote matching?

asm!("syscall" : "{rax}" = n -> ret, {rdi}" = a1, "{rsi}" = a2, "rcx", "r11", "memory", "volatile");

vs.

asm!("syscall" : "{rax}" = n -> ret, "{rdi}" = a1, "{rsi}" = a2, "rcx", "r11", "memory", "volatile");

Also, why is there a : in there? Shouldn't that be a comma? Or am I misunderstanding?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, that should be a comma.

@pczarn
Copy link
Author

pczarn commented Jun 18, 2014

cc @luqmana

@Tobba
Copy link

Tobba commented Jun 23, 2014

cc me

@pnkfelix
Copy link
Member

we should probably ensure that whatever, we do, we attempt to have a clean separation between the surface level syntax (or syntax_es_) that is exposed to end-users, versus whatever internal AST representation is used within the rustc compiler.

It might be best of all to expose a low-level macro or intrinsic that closely mirrors rustc's AST node, and then allow third-party libraries provide nicer sugar on top of that -- that was why i mentioned "syntaxes" parenthetically above. Or maybe that is contrary to the goals of this RFC.

(Also, there are some bugs in the current asm!. I'll note them here for completeness; they are only tangentially relevant to this RFC in that one should take pains to ensure that whatever design we adopt does not build any similar bugs into its design. Bugs: rust-lang/rust#14936 rust-lang/rust#14962 )

@Ericson2314
Copy link
Contributor

Definitely a step in the right direction, pczarn! There are loads of stuff we can do better than clang/gcc.
I would like to see output args not necessitate mutation. Based on the scanln! rfcs discussion, something like let (x, y) = asm!(...); might be nice. Alternatively the asm! macro itself could do the binding.

Also I am just going to leave https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41045 . I can't remember my specific problem which led me to this bug long ago, but there was something. Perhaps rust's static lifetime could be leveraged to make this possible?

@pczarn
Copy link
Author

pczarn commented Jul 22, 2014

@pnkfelix, agreed. After reading the issues, I'm afraid that the internal AST will have to represent read+write operands. So the internal representation will get closer to the current surface level syntax.

Everything proposed in this RFC could be provided in a third-party library.

@Ericson2314, I see that the scanln! discussion is relevant. It's still unclear to me how to choose which parameters are returned in certain order from asm!.

There is a subtle interaction between inputs, outputs, and assigned registers. The design must offer more complex features than scanln! would have.

Toplevel assembly is another matter. There is no way of having unsafe blocks in item position. I recall only a short discussion about naked fns.

@nikomatsakis
Copy link
Contributor

One concern I have off the top of my head is that, while gcc/clang is undoubtedly a terrible syntax, it's the devil we know. This means that, for example, using the current syntax it is easy to copy/paste examples from stackoverflow.

@Ericson2314
Copy link
Contributor

Obviously cutting and pasting C or C++ as Rust won't work. Would people expect otherwise with inline assembly? For what it is worth, D seems to have also gone in the direction of defining its own system: http://dlang.org/iasm.html .

If you think it's very import I'd hope Rust's macro-based approach would allow us to do both with little extra code.

@pczarn
Copy link
Author

pczarn commented Jul 22, 2014

One concern I have off the top of my head is that, while gcc/clang is undoubtedly a terrible syntax, it's the devil we know. This means that, for example, using the current syntax it is easy to copy/paste examples from stackoverflow.

While I agree, as it's the first drawback noted in the RFC, copying unsafe code like that is dangerous. Inline assembly is tricky and the syntax is not even identical across gcc/clang/Rust. Probably not a good practice.

There was a conversation (started by @Zoxc) on #rust-osdev about output operands, other details, D lang &c. I'll update the RFC accordingly.

@huonw
Copy link
Member

huonw commented Aug 14, 2014

The asm! syntax extension currently works by taking its arguments and converting it into a form that LLVM understands, passing it as an inline assembler expression via the AST node. After discussing at the meeting we think this can and should be experimented with via an external syntax extension; the conversion step of the asm! syntax extension is very simple (do nothing), but there's no reason why someone couldn't write fancy_asm! that does more compilcated processing.

This will provide significantly easier iteration, and will not pin the exact support to what we wish to support in the core language (hopefully encouraging more diversity & experimentation). It may turn out to be hard/impossible, but I'm sure there's a little bit of scope for adjusting the compiler internals to assist, and if that's not enough, we can revisit this RFC (or one like it) once we've established it needs to be more deeply in the language.

As such, I'm closing this; thanks for thinking about improving this part of Rust!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants