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

[Song, J. K. <jin...@in...>]

> -----Original Message-----
> From: anonymous coward [mailto:nas...@us...]
> Sent: Tuesday, August 06, 2013 6:15 AM
> To: nas...@li...
> Subject: Re: [Nasm-devel] [PATCH] AVX-512: Add support for parsing braces
> 
> > 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.  ;-)

Yes, you are right. AVX-512 introduced curly-brace to NASM. ;-)

> 
> > + * 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.

This statement misleads. I meant that opmask and zeroing decorators can be placed in any order. I will reword this line.

> 
> > + * 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.)

Fairly reasonable. I will simplify the parsing logic along with removing support for commas and nested braces.

> 
> 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.

Could you explain a little bit more about this? Is it regarding {er} and {sae} that are put as if they are separate operands?

> 
> 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.
>