Stream: project-inline-asm

Topic: options() versus top-level options


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

@Amanieu Thanks for the updates to the RFC. Do you have thoughts on the proposal to take the parameters of options() and make them top-level parameters of asm! instead? That seems like a useful simplification for anyone actually using options.

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

That would prevent us from using options that could get mistaken for in/out and similar, but that doesn't seem like a problem.

Amanieu (Jan 21 2020 at 20:54, on Zulip):

Eh, I'm somewhat torn on this issue. There's a lot of freedom in how we can deal with options.

Amanieu (Jan 21 2020 at 20:54, on Zulip):

For example, we could remove the requirement that they appear at the end of the argument list.

Amanieu (Jan 21 2020 at 20:55, on Zulip):

But I think this is getting into bikeshed territory: it doesn't really matter what option we pick, people will just go with it.

Josh Triplett (Jan 22 2020 at 18:13, on Zulip):

I don't think they'd need to appear at the end of the argument list either way. We would just need to ensure that they have unique names.

Amanieu (Jan 22 2020 at 18:16, on Zulip):

One reason for putting them at the end is that they make positional arguments more confusing

Josh Triplett (Jan 22 2020 at 18:16, on Zulip):

That's completely fair, but it's also true whether they're wrapped in options() or not.

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

I do actually prefer requiring that they appear at the end.

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

I'm just suggesting that the following seems reasonable to me:

    asm!(
        "add {0}, {1}",
        inlateout(reg) a, in(reg) b,
        pure, nomem, nostack
    );
Amanieu (Jan 22 2020 at 18:18, on Zulip):

I'm worried that the options might get confused with operands as we add more operand types.

simulacrum (Jan 22 2020 at 18:19, on Zulip):

one alternative is to move the options to e.g. an attribute atop the macro? not sure how that would fare though

simulacrum (Jan 22 2020 at 18:19, on Zulip):

but that is pretty clearly "separate"

Amanieu (Jan 22 2020 at 18:19, on Zulip):

Such as those listed in the future work section of the RFC: fallthrough and label for asm goto, flag_out, etc.

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

@simulacrum Options on expressions seem a little more confusing to read, to me.

simulacrum (Jan 22 2020 at 18:20, on Zulip):

hm, I think of asm! as more of an item

simulacrum (Jan 22 2020 at 18:20, on Zulip):

but yes, that's true

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

My personal feeling is to leave it as options(). But this is very easy to change if we decide otherwise in the future.

Josh Triplett (Jan 22 2020 at 18:20, on Zulip):

I'm suggesting that we should decide this in the RFC.

Josh Triplett (Jan 22 2020 at 18:20, on Zulip):

I certainly agree that it will make slightly more work for us in the parser.

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

The tradeoff is that every single user of asm! will get simpler syntax.

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

We just have to make sure we don't create option names that conflict with the other types of arguments you can pass to asm!. That doesn't seem especially problematic.

simulacrum (Jan 22 2020 at 18:21, on Zulip):

it is true that we can stop requiring options later, right?

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

(For instance, we can't name an option lateout. ;) )

Josh Triplett (Jan 22 2020 at 18:40, on Zulip):

I absolutely understand that options() makes the parser a little simpler. But do you see any fundamental limitations we'd have without it that justify making everyone write it for every asm that has options?

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

could the options list at the end be "transitioned to" with a separation other than ,? Such as using ; to show the larger distinction.

    asm!(
        "add {0}, {1}",
        inlateout(reg) a, in(reg) b;
        pure, nomem, nostack
    );
Josh Triplett (Jan 22 2020 at 21:50, on Zulip):

It could be, but that seems like a syntax annoyance to have to remember, and one that people will regularly forget.

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

(To the point that I think we'd end up making the parser handle , anyway just to give good error messages, at which point we could just make that the syntax.)

Lokathor (Jan 22 2020 at 22:04, on Zulip):

Yeah I think all , is best, but I'm also not personally worried about template param order getting confused even with top level options (which I'm in favor of), so it's hard to understand a good fix.

We could make all the separations be flexible? Like how macros accept any outer grouping as a legal way to use them?

Amanieu (Jan 22 2020 at 22:14, on Zulip):

Don't worry about the parser complexity, that is absolutely trivial compared to the rest of the work.

Amanieu (Jan 22 2020 at 22:15, on Zulip):

I don't have any strong objections on either options() or top-level options: both would likely work fine in practice.

Josh Triplett (Jan 22 2020 at 22:39, on Zulip):

@Amanieu If you don't have any objections to either, then I do have a preference for top-level options, to reduce the verbosity of asm! statements.

Amanieu (Jan 22 2020 at 22:40, on Zulip):

Ok then, let's do that.

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

Thank you.

Amanieu (Jan 22 2020 at 23:10, on Zulip):

Actually I just thought of a possible argument for keeping options(): it looks better when operands are formatted on a separate line each, since the options are all on one line.

Amanieu (Jan 22 2020 at 23:10, on Zulip):
asm!(
    "longer asm {x} {y} {z}",
    x = in(reg) long_expression_1,
    y = in(reg) long_expression_2,
    z = out(reg) long_destination_3,
    options(nomem, pure, nostack, preserves_flags),
);
Josh Triplett (Jan 22 2020 at 23:19, on Zulip):

We can absolutely propose a formatting of asm! that puts options on the same line even if they're not inside options().

Josh Triplett (Jan 22 2020 at 23:19, on Zulip):
asm!(
    "longer asm {x} {y} {z}",
    x = in(reg) long_expression_1,
    y = in(reg) long_expression_2,
    z = out(reg) long_destination_3,
    nomem, pure, nostack, preserves_flags,
);
Josh Triplett (Jan 22 2020 at 23:19, on Zulip):

That's how I would want to format that, personally.

Last update: Jun 07 2020 at 10:40UTC