Stream: project-inline-asm

Topic: Moving forward with the RFC


Amanieu (Jan 10 2020 at 10:20, on Zulip):

At this point the draft RFC is almost ready. The last issue that needs to be resolved is rust-lang/project-inline-asm#5.

Amanieu (Jan 10 2020 at 10:21, on Zulip):

Basically we need a specification for what implicit state inline asm is/isn't allowed to modify.

Amanieu (Jan 10 2020 at 10:21, on Zulip):

And define the exact semantics of preserves_flags.

gnzlbg (Jan 10 2020 at 12:18, on Zulip):

@Amanieu i'm not sure what to think about that

gnzlbg (Jan 10 2020 at 12:19, on Zulip):

on one hand, we want to tell the compiler to assume the worst about asm! blocks, to prevent mistakes, like the user forgetting to write invalidates_flags

gnzlbg (Jan 10 2020 at 12:19, on Zulip):

(which is why preserves_flags is an extra guarantee)

gnzlbg (Jan 10 2020 at 12:20, on Zulip):

on the other, it would be simpler to just say that an asm! can do the same things as an unknown function call, but I guess that defeats the point

gnzlbg (Jan 10 2020 at 12:20, on Zulip):

its unclear to me how not writing preserves_flags would work

gnzlbg (Jan 10 2020 at 12:21, on Zulip):

does it mean that asm!("...modifies flags..."); asm!("...assert modification or panic...") is guaranteed to "never panic" ?

gnzlbg (Jan 10 2020 at 12:22, on Zulip):

afaict llvm could modify the flags between both asm! statements

gnzlbg (Jan 10 2020 at 12:22, on Zulip):

or maybe worse, insert some code in-between that assumes that these flags have not been modified

Amanieu (Jan 10 2020 at 12:44, on Zulip):

Basically preserves_flags is intended as the inverse of the "cc" clobber.

bstrie (Jan 10 2020 at 19:12, on Zulip):

If I wanted to leave some questions/feedback on the pre-RFC in the repo there, is opening an issue in the repo the best place to do that?

Amanieu (Jan 10 2020 at 20:43, on Zulip):

@bstrie Yes, please do.

Amanieu (Jan 11 2020 at 21:56, on Zulip):

OK I just posted rust-lang/project-inline-asm#10, which fixes our last unresolved issue.

Amanieu (Jan 11 2020 at 21:57, on Zulip):

I'll publish the RFC once it is merged, so if you have any feedback in mind please say so now.

Amanieu (Jan 11 2020 at 21:57, on Zulip):

Don't worry if you miss it, there is still the possibility of providing feedback during the official RFC process.

Amanieu (Jan 12 2020 at 17:19, on Zulip):

@Josh Triplett Since you're the lang team liason, do you have any objections to publishing the RFC once rust-lang/project-inline-asm#10 is merged?

Amanieu (Jan 13 2020 at 15:24, on Zulip):

The RFC is now up at rust-lang/rfcs#2850!

bstrie (Jan 13 2020 at 19:27, on Zulip):

Ah, I didn't realize the rfc was about to be published so I didn't rush :P I've just left some comments on the rfc

Josh Triplett (Jan 15 2020 at 20:30, on Zulip):

Sorry that I didn't see this message, but the answer at the time was "no, no objections, go ahead". :)

gnzlbg (Jan 20 2020 at 16:24, on Zulip):

@Amanieu what happens with backends that do not support inline assembly for a particular target ?

gnzlbg (Jan 20 2020 at 16:24, on Zulip):

The RFC mentions that we can always implement inline assembly without backend support

gnzlbg (Jan 20 2020 at 16:25, on Zulip):

but my question is more: what happens until somebody implements that?

gnzlbg (Jan 20 2020 at 16:25, on Zulip):

Trying to use the backend for that target should fail, but the RFC does not say

gnzlbg (Jan 20 2020 at 16:26, on Zulip):

I expect it to be possible to use such Rust backends to compile Rust programs, as long as these programs do not try to use anything that uses asm!

gnzlbg (Jan 20 2020 at 16:26, on Zulip):

but if they try to use asm!, then I expect a nice error

Amanieu (Jan 20 2020 at 17:22, on Zulip):

I expect that adding fallback asm support would be a requirement to adding new backends if they don't support inline asm

Amanieu (Jan 20 2020 at 17:22, on Zulip):

Basically, I don't want asm! to depend on the particular backend in use.

Amanieu (Jan 20 2020 at 17:22, on Zulip):

It should just work.

Lokathor (Jan 20 2020 at 17:23, on Zulip):

That sounds like the opposite of a good time

gnzlbg (Jan 20 2020 at 18:17, on Zulip):

@Amanieu that means that we need to break powerpc, sparc64, wasm, and all other targets on stable Rust the moment asm! gets stabilized

gnzlbg (Jan 20 2020 at 18:17, on Zulip):

or

gnzlbg (Jan 20 2020 at 18:17, on Zulip):

that we can't stabilize asm! until all currently supported targets on stable using the LLVM wrapper work

gnzlbg (Jan 20 2020 at 18:18, on Zulip):

(that requires submitting RFCs implementing asm! for all targets currently supported on stable, which are many)

gnzlbg (Jan 20 2020 at 18:19, on Zulip):

notice that I'm not talking about backends

gnzlbg (Jan 20 2020 at 18:19, on Zulip):

I'm talking about targets within a backend

gnzlbg (Jan 20 2020 at 18:20, on Zulip):

e.g., if LLVM adds support for a new target, then a rust LLVM upgrade must be blocked on either implementing asm! for that target, or implementing a check that rejects that target

gnzlbg (Jan 20 2020 at 18:21, on Zulip):

for LLVM this might be minor, but the amount of work required to support a new target for cranelift isn't minor

gnzlbg (Jan 20 2020 at 18:21, on Zulip):

this means that as backends add support for new targets, we'll be blocking being able to use them from Rust until somebody implements asm! support for them

gnzlbg (Jan 20 2020 at 18:21, on Zulip):

that seems unreasonable

Amanieu (Jan 20 2020 at 18:25, on Zulip):

We can stabilize asm! for different architectures separately.

Amanieu (Jan 20 2020 at 18:25, on Zulip):

Keep in mind the new asm! need specific rustc support for each architecture, so an LLVM upgrade won't break existing targets.

Amanieu (Jan 20 2020 at 18:26, on Zulip):

The way I see it working is that initially cranelift will use the external assembler for all targets, and as support is added then some of these will switch to the builtin cranelift support/

gnzlbg (Jan 20 2020 at 18:32, on Zulip):

So... suppose we stabilize asm! for RISC-V

gnzlbg (Jan 20 2020 at 18:32, on Zulip):

and that works, because we can only use the LLVM backed for RISC-V

gnzlbg (Jan 20 2020 at 18:32, on Zulip):

then Cranelift adds support for RISC-V, and cranelift does not support inline assembly

gnzlbg (Jan 20 2020 at 18:33, on Zulip):

we upgrade Cranelift in rustc, shall we block the Cranelift upgrade on adding either support for asm! on cranelift for RISC-V or on forbidding users of the Cranelift backed to target RISC-V after the upgrade?

gnzlbg (Jan 20 2020 at 18:34, on Zulip):

even if we were to use the external assembly for cranelift, we would need to add support to rustc for using an external assembler for riscv

gnzlbg (Jan 20 2020 at 18:35, on Zulip):

since we did not need that for the LLVM backend, and I doubt one can "reuse" the code for other assemblers, since each assembly language for each target is sufficiently different

Amanieu (Jan 20 2020 at 19:10, on Zulip):

I don't expect the external assembler part to be too difficult. It is indeed arch-specific, but it shouldn't be too difficult to port once the initial support has been implemented.

Lokathor (Jan 20 2020 at 20:32, on Zulip):

It seems far better to make asm! a "bonus" ability for a target to have, and not block adding a target based on asm! being supported or not. The same as we would not block a new target based on complete core::arch support or not.

simulacrum (Jan 20 2020 at 20:57, on Zulip):

er, target yes, I think (maybe fits into "tiers" in some sense), but I believe @Amanieu is more so talking about codegen backends

simulacrum (Jan 20 2020 at 20:57, on Zulip):

i.e., we would expect all codegen backends to support asm (in some fashion), but maybe some non-tier 1 targets don't

simulacrum (Jan 20 2020 at 20:57, on Zulip):

and I think that fits into assembly well overall anyway, right? Since for e.g. ARM you'd need different assembly presumably?

Lokathor (Jan 20 2020 at 21:19, on Zulip):

(Also we should maybe try to be extra clear going forward in this thread what is a requirement for rust the language, in terms of being a compliant compiler of that language, and what's a requirement for rustc itself, being a specific compiler of that language.

And then with that distinction we can also question what non-rustc compilers, such as Cranelift and any other future compilers, would have to do to be considered a working rust compiler.)

simulacrum (Jan 20 2020 at 21:37, on Zulip):

I don't think that distinction is meaningful at this point; there is really only one Rust compiler.

simulacrum (Jan 20 2020 at 21:37, on Zulip):

or at least I don't see how anything I've seen so far is affected by it

Lokathor (Jan 21 2020 at 00:18, on Zulip):

people have definitely been concerned this whole time how any of this affects Cranelift.

simulacrum (Jan 21 2020 at 02:38, on Zulip):

Sure - but that's not an issue of language spec or not, I think? i.e. we're only ever discussing basically language spec

Lokathor (Jan 21 2020 at 04:44, on Zulip):

Amanieu said "we can stabilize asm! for different targets separately", and that is pretty obviously a statement of proposed Mozilla Rustc policy. That clearly can't be language spec policy. The language itself either contains asm! or not. Those are the only two possible states. Beyond that the support level per compilation target is a compiler specific concern.

You mentioned non-tier 1 targets, but the entire tier target policy is also a Mozilla Rustc concern, I don't think that Cranelift or any other compiler needs to subscribe to the same tiering or tier qualifications as Mozilla Rustc uses.

So it's a totally fair question to ask for clarification to the question of "what happens when a compiler doesn't support inline asm! on a given target?" And the answer is going to be a little bit language spec and a lot bit Mozilla Rustc, and then other compiler projects are going to have to decide what they want to do as well based on the little bit that's language spec.

Jake Goulding (Jan 21 2020 at 15:36, on Zulip):

A bit tangential, but that question goes beyond asm!. For example, mrustc doesn't currently support borrow checking — is it "a Rust compiler"?

Josh Triplett (Jan 21 2020 at 17:17, on Zulip):

@Lokathor Please don't use the phrase "Mozilla rustc". There's only the one rustc, and it's not a Mozilla project, it's the compiler built by the Rust community.

Josh Triplett (Jan 21 2020 at 17:19, on Zulip):

@Lokathor If you really want to distinguish between "the Rust compiler" and "the Rust language" (as theoretically implementable by another compiler), by all means, but the Rust compiler is not owned by Mozilla or any other company.

Josh Triplett (Jan 21 2020 at 17:21, on Zulip):

@Jake Goulding IIn a literal sense, mrustc is a simplistic Rust compiler for an old version of Rust, but it's missing a critical piece of error-checking for incorrect code. (That doesn't make it an uninteresting project; on the contrary, it's interesting for bootstrapping without needing ocaml, and for doing diverse double-compilation.) In a more practical sense, mrustc is never going to define the Rust language, and will almost certainly always lag the Rust compiler. Its limitations are not Rust language limitations.

Lokathor (Jan 21 2020 at 17:39, on Zulip):

"mozilla rustc" is just the term that some folks used in the Rust Foundation Proposal topic on internals. Specifically the point was made that any alternative rust compiler wishing to work with standard tooling would likely have to take on the name rustc the same as various java compilers all use javac as their installed name.

Josh Triplett (Jan 21 2020 at 17:42, on Zulip):

A compiler that wanted to install itself as rustc would need to support not only Rust as implemented by the Rust compiler, but also the rustc command-line interface. That's theoretically possible, but seems vanishingly unlikely.

Josh Triplett (Jan 21 2020 at 17:43, on Zulip):

Ever since Java became Open Source, alternative Java compilers have become far far less common. Alternative implementations of a compiler are far more critical when the primary implementation isn't open.

Josh Triplett (Jan 21 2020 at 17:45, on Zulip):

I'm not saying someone can't implement another Rust compiler, just that doing so and calling it rustc doesn't seem especially useful (and seems more likely to generate confusion than compatibility).

Josh Triplett (Jan 21 2020 at 17:46, on Zulip):

In any case, we're trying very hard to avoid the incorrect perception that Rust is a Mozilla project, and I'm asking to please avoid terminology that contributes to that perception.

Lokathor (Jan 21 2020 at 17:49, on Zulip):

rust project rustc it is

Josh Triplett (Jan 21 2020 at 17:50, on Zulip):

Thank you, that's an improvement. :)

Jake Goulding (Jan 21 2020 at 18:08, on Zulip):

@Josh Triplett that makes sense, but I fear you went too deeply into my concrete example, so let's use a hypothetical: I clone rust-lang/rust and find the secret "run the borrow checker" flag, set it to false, and publish that compiler. Is it "a Rust compiler"? Replace "run the borrow checker" with any given aspect of what we generally consider "Rust".

Ultimately, it's the line between language spec and implementation, which we know is not as well defined as we'd like right now.

Josh Triplett (Jan 21 2020 at 18:11, on Zulip):

It would be a Rust compiler, specifically a Rust compiler that nobody should use, it would be a misleading thing to do to continue calling it "rustc", and most importantly, the capabilities of that compiler should not affect what we describe as "Rust" when we talk about the Rust language.

Josh Triplett (Jan 21 2020 at 18:14, on Zulip):

To more directly answer the distinction you're making:

Josh Triplett (Jan 21 2020 at 18:17, on Zulip):

I think there's value in having a Rust language specification, to help people understand and reason about the language.

Josh Triplett (Jan 21 2020 at 18:19, on Zulip):

I don't think that the language specification, by itself, is what people should anchor to in an alternate implementation. And in particular, I think in practice someone would want to say "Rust as implemented by rustc 1.x", not "Rust as defined in the 1.x language specification". If those turned out to differ, it would be just as likely to be a bug in the language specification as a bug in rustc.

Lokathor (Jan 21 2020 at 18:42, on Zulip):

Well I don't think we'd update a language spec every 6 weeks

Lokathor (Jan 21 2020 at 18:44, on Zulip):

so, like with C++ or Haskell or pick your favorite, i expect the language specification would get some definition, then anything going into a rust compiler after that would be not in the spec until some update point when we edit the spec after X years of experimentation

Josh Triplett (Jan 21 2020 at 18:49, on Zulip):

@Lokathor I really hope that once we have a language specification we update the language specification every time we change the language.

Josh Triplett (Jan 21 2020 at 18:49, on Zulip):

I'm hoping it lives in the rust repository.

Lokathor (Jan 21 2020 at 18:50, on Zulip):

oof

Josh Triplett (Jan 21 2020 at 18:50, on Zulip):

(I sincerely hope that anyone talking about a "language specification" here is referring to a document, not something from ANSI or ISO or similar.)

Josh Triplett (Jan 21 2020 at 18:51, on Zulip):

Why would we want a language specification to lag the actual language?

Lokathor (Jan 21 2020 at 18:56, on Zulip):

that's a whole other thing that feels way off topic to the inline assembly RFC :3

Josh Triplett (Jan 21 2020 at 18:59, on Zulip):

That's certainly true. :)

centril (Jan 22 2020 at 16:38, on Zulip):

that makes sense, but I fear you went too deeply into my concrete example, so let's use a hypothetical: I clone rust-lang/rust and find the secret "run the borrow checker" flag, set it to false, and publish that compiler. Is it "a Rust compiler"? Replace "run the borrow checker" with any given aspect of what we generally consider "Rust".

I don't think it is a Rust compiler if it allows more or less programs than the spec allows

centril (Jan 22 2020 at 16:38, on Zulip):

at least it's not a Rust compiler for that version of the spec

centril (Jan 22 2020 at 16:39, on Zulip):

So I don't think mrustc is a Rust compiler, though a useful tool nonetheless

centril (Jan 22 2020 at 16:39, on Zulip):

I'm hoping it lives in the rust repository.

Well, rust-lang/{reference, spec}, but close enough? ;)

Lokathor (Jan 22 2020 at 21:29, on Zulip):

Most C compilers allow more than the spec allows, and we still call them C compilers.

centril (Jan 22 2020 at 22:30, on Zulip):

Here (as in most cases), C is a motivating example of what not to replicate, in my view

Lokathor (Jan 23 2020 at 00:16, on Zulip):

Well I guess GHC isn't a Haskell compiler either then ;3c

centril (Jan 23 2020 at 00:47, on Zulip):

GHC is basically the only Haskell compiler used in production, and Haskell is more of a research language than Rust, so I think the situation is not comparable

Josh Triplett (Jan 23 2020 at 04:57, on Zulip):

I think it might be a bit far to say that mrustc isn't a Rust compiler. That doesn't seem like an especially helpful definition, semantically. I would more say that rust-lang/rust defines Rust, and mrustc implements only a subset of Rust. mrustc or any other Rust implementation doesn't define what Rust is, or the limitations or capabilities of Rust.

Last update: Apr 05 2020 at 00:45UTC