Re: [Nasm-devel] [PATCH] AVX-512: Add support for parsing braces

[anonymous c. <nas...@us...>]

> AVX-512 introduced new syntax using braces for decorators.

Actually, the curly-brace operand modifiers were introduced
by L1OM on Larrabee. Also, K1OM used them on Xeon Phi.
AVX-512 is merely the third x86 extension to use them.  ;-)

> + * the order of decorators does not matter.

The order matters in terms of which one wins in case of any
conflict, i.e. first vs last, warning vs error, etc.

You should consider following gas behavior, simply because
it effectively set the standard for this a long time ago.

> + * e.g. zmm1 {k2}{z} or zmm2 {z,k3}

You really do NOT want that comma syntax, for two reasons.

First, it poses a problem if a vendor ever introduces a future
modifier with a comma in it. For example, {a,b,c,d}.

Second, it will simplify parsing/tokenizing. Because instead
of having to bastardize the existing clean identifier handling
with exceptions for curly braces and dashes, and exceptions
for nested braces and multiple qualifiers, you'll end up with a
rather simpler and more traditional sequence: opening curly
brace, optional whitespace, a sequence of non-whitespace
characters (that gets looked up against known qualifiers, in
e.g. a hash table), optional whitespace, plus a closing curly
brace. (Put another way, your modifications to that parsing/
tokenizing code are very intrusive, and difficult to validate
when it comes to corner cases.)

In terms of modifier placement you probably want to look at
gas again -- I have seen code which has modifiers before an
operand, and I have seen code which has them as their own
operand. For example, {one} op1, {two}, op2.

I do not know if you care about supporting L1OM and K1OM
eventually -- the longer you wait, the more obsolete they will
be, of course :-) -- but that would come with more challenges.
In particular, the regular braces which were used to enclose
operands decorated with transform modifiers are really hard
to get right.