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

Introduce the ASM project group #2836

Open
wants to merge 3 commits into
base: master
from
Open

Conversation

@Amanieu
Copy link
Contributor

Amanieu commented Dec 10, 2019

Rendered

@Amanieu

This comment has been minimized.

Copy link
Contributor Author

Amanieu commented Dec 10, 2019

The reposity link is currently broken, could someone with the appropriate permissions create rust-lang/project-asm?

@Ekleog

This comment has been minimized.

Copy link

Ekleog commented Dec 10, 2019

@Amanieu Amanieu force-pushed the Amanieu:project-asm branch from 6bd89bc to 9b40dec Dec 11, 2019
@joshtriplett joshtriplett self-assigned this Dec 13, 2019
@joshtriplett joshtriplett added the T-lang label Dec 13, 2019
@joshtriplett

This comment has been minimized.

Copy link
Member

joshtriplett commented Dec 13, 2019

This looks great to me. We already discussed this in last week's language team meeting, and this proposal is just to charter the team to work on the problem rather than endorsing any particular solution, so let's go ahead and get consensus and get this rolling!

@rfcbot merge

@rfcbot

This comment has been minimized.

Copy link

rfcbot commented Dec 13, 2019

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@gnzlbg
gnzlbg approved these changes Dec 13, 2019
Copy link
Contributor

gnzlbg left a comment

Sounds great!

@fintelia

This comment has been minimized.

Copy link

fintelia commented Dec 15, 2019

Certain elements are definitively out of scope:

  • The chosen asm! syntax should not involve rustc "understanding" the asm code itself, since this would require a huge amount of work in the compiler to support the full assembly syntax of multiple architectures. Instead, interpretation of the assembly code should be left to the compiler backend (LLVM) or an external assembler (GAS).

Is this saying that the resulting design must have rustc treat the asm code as an opaque string, or just that rustc can't be expected to compile the code itself? There is vast middle ground between these two requirements. For instance, the project group might want to define a single comment syntax so higher level tools (like say syntax highlighters) can at least partially interpret the code

@Lokathor

This comment has been minimized.

Copy link

Lokathor commented Dec 15, 2019

That sounds neat, but also that sounds like something that should wait for the project group to be accepted and then have that discussion of the details there.

@fintelia

This comment has been minimized.

Copy link

fintelia commented Dec 15, 2019

I'm not super familiar with how Rust project groups operate, but my expectation would be that if the charter says something is out of scope, then the project group isn't "allowed" to discuss it. That's why I'm hoping to clarify the group scope before it is accepted/started. (This is of course the wrong place to debate my hypothetical comment syntax proposal, I just wanted to give an example of an issue that I wasn't sure if it was germane or not)

@Amanieu

This comment has been minimized.

Copy link
Contributor Author

Amanieu commented Dec 15, 2019

The scope is intentionally a bit vague here. The intent is that we do not want to have to re-implement a whole assembler ourselves, for every supported architecture.

@Ekleog

This comment has been minimized.

Copy link

Ekleog commented Dec 15, 2019

I had the exact same reaction while reading this sentence, and hesitated commenting on it. Maybe it'd make sense to just remove that “this is out of scope” line, so that the ambiguity is not there and the project group can just reasonably end up with the conclusion that the solution is not going to be re-implementing a whole assembler?

For instance, I seem to remember some pretty convincing arguments saying that all stable asm should actually be at least completely parsed by rustc, if not more, which comes close enough to “re-implement a whole assembler ourselves” to be in the gray zone, as far as I understand.

@Ixrec

This comment has been minimized.

Copy link
Contributor

Ixrec commented Dec 15, 2019

For instance, I seem to remember some pretty convincing arguments saying that all stable asm should actually be at least completely parsed by rustc, if not more

I'm guessing this is https://internals.rust-lang.org/t/inline-assembly-syntax/239/5, which was brought up in the recent irlo inline asm thread here: https://internals.rust-lang.org/t/pre-rfc-2-inline-assembly/11310/102

Although I disagree with these arguments, I do think it's reasonable to expect that some future RFC produced by the ASM project group will explicitly say "we didn't go with asm-as-syntax for reasons X, Y, Z", and "because the charter said so" would be a pretty unsatisfying reason. So I'd also be fine with removing that "out of scope" qualifier for now. It's not like there's another Rust project group working on reimplementing assemblers or assembly syntax, and assembly syntax is certainly relevant to the whole discussion of inline asm (as opposed to e.g. how two-phase borrows are technically irrelevant to NLL, and that was worth highlighting on NLL-related issues since it's not obvious).

@elichai

This comment has been minimized.

Copy link

elichai commented Dec 17, 2019

Love it :)

@joshtriplett

This comment has been minimized.

Copy link
Member

joshtriplett commented Jan 2, 2020

@Amanieu

This comment has been minimized.

Copy link
Contributor Author

Amanieu commented Jan 12, 2020

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Jan 13, 2020

We discussed this some in our lang team meeting last Thursday. @Centril expressed some concerns, though it would be helpful if he could elaborate them, since I don't think I have a great grasp of what they are. One thing that he raised I know is a question of whether we'll have the bandwidth available to tackle this.

I personally feel pretty good about this, since I think that

  • the interaction of inline assembly with the compiler is generally broad but shallow. That is, I feel like inline assembly touches a lot of the compiler, but it doesn't usually require very complex modifications to any one piece.
  • @Amanieu is (as I understand it) volunteering to do a lot of the implementation work, and @joshtriplett is happy to help summarize and bring things to lang team.

In particular I'd like for the @rust-lang/lang team to get better at being able to "delegate" projects like this. The hope would be that the group can handle figuring out the right path, and keep the team updating both via RFCs and regular updates.

As far as priority, I feel that this fits our current project goals in a few ways:

  • I would like us to be taking unfinished features with no particular path to stability and either removing them or finishing them off. Prioritization in these cases can be hard, because most individual features may not be that high priority one by one, but I think that reducing their number is valuable.
  • As for this individual feature, it falls in a few categories ("systems programming", "C parity") that I think are important, and I think that it is clearly of high importance to many potential adopters (especially given the interest we've seen). I think it's important for Rust to both have capabilities that rival C in terms of enabling low-level, systems applications, but also to do a good job on their design.

One thing that would be helpful is if we had some folks from @rust-lang/compiler (or @rust-lang/compiler-contributors) who was excited to serve as a dedicated reviewer here.

@rfcbot

This comment has been minimized.

Copy link

rfcbot commented Jan 13, 2020

🔔 This is now entering its final comment period, as per the review above. 🔔

@Amanieu

This comment has been minimized.

Copy link
Contributor Author

Amanieu commented Jan 13, 2020

Incidentally, we've just finished the RFC for inline assembly and it is now up at #2850.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.