-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Conversation
within the assembly string: | ||
|
||
```rust | ||
asm!("syscall" : "{rax}" = n -> ret, {rdi}" = a1, "{rsi}" = a2, "rcx", "r11", "memory", "volatile"); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
cc @luqmana |
cc me |
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 |
Definitely a step in the right direction, pczarn! There are loads of stuff we can do better than clang/gcc. 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? |
@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 There is a subtle interaction between inputs, outputs, and assigned registers. The design must offer more complex features than 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. |
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. |
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. |
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. |
The 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! |
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.