Re: [Nasm-devel] Xeon Phi

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

>> However, support for parentheses around an
>> operand (as suggested by #327364-001 3.5)
>> is tricky: for reg ops the parentheses simply
>> evaluate, but for mem ops the parser has to
>> explicitly skip them -- however, that decision
>> hinges on the leading transform modifier and
>> there is no clear reg versus mem distinction,
>> because of the D(...) down converts: they do
>> use reg ops, but with mem transforms.
>>
>> I have not decided the most suitable course
>> yet -- add extra parse-ahead to find '[', parse
>> down convert instructions specially, or, well,
>> ignore Intel's suggested syntax (i.e. no (...),
>> and permit all modifiers before and after any
>> operand, reg or mem [with subsequent tests
>> for their sanity/validity, of course]).
>
> Cyrill and I looked at this last night, and we're not entirely sure what you
> mean.  Our thinking has been to treat braced keywords simply as a separate
> keyword space, which would mean a slightly looser syntax but probably okay.
> I seriously did not follow the big about parens, though...

The KNC ISA PDF suggests this operand syntax:

  {transform} ( op {hint} ) {mask}

  - {eh} can follow memory operand, i.e. [...] {eh}
  - {transform} can precede specific source operand
  - {mask} can follow destination operand
  - the parentheses around op and {hint} are explicit

I have come to refer to that as the canonical form.

By contrast, a relaxed syntax would permit these:

  - incorrect source operand has transform modifier
  - non-destination operand has mask modifier

  - transform modifier specified after operand
  - eviction hint specified before operand
  - mask modifier specified before operand

  - transform modifier operand not preceded by "("
  - transform modifier operand not followed by ")"

  - eviction hint specified after ")", not before
  - mask modifier specified before ")", not after

  - transform modifier invalid for memory operand
  - transform modifier invalid for register operand

  - modifier specified as extra operand

And for that last "specified as extra operand" case:

  - only operand --> ignored
  - leading operand --> applied to next operand
  - trailing operand --> applied to previous operand
  - in between operands --> applied to previous operand

The problem with the "(" and ")" in the canonical form:

  {transform} ( reg op ) --> parentheses will evaluate
  {transform} ( mem op ) --> parentheses won't evaluate

  finding ")" after mem op --> easy
  finding ")" after reg op --> hard

So always skipping "(" is hard because finding ")" is.

And to avoid having to scan ahead for reg vs mem op,
the skip decision must be made based on {transform}.

Since D(...) down converts use reg ops, but have mem
transform modifiers, those instructions require special
treatment. (I did managed to make that work after all.)

That said...

I do have functional KNC support.
I am still working on KNF support.

KNF became obsolete after KNC arrived.
KNC might be obsolete after AVX3 arrives.

Before burdening the assembler with KNF and KNC, it
might make sense to await the AVX3 spec, to find out
what "pieces" will actually be required in the long term.

So far it looks like:

  - support for {modifier} tokens
  - support for one or more of them before any operand
  - support for one or more of them after any operand
  - support for one or more of them without any operand

  versus

  - constrains on which modifier token(s) can be used,
    based on KNC/KNF/AVX3, instruction, operand, etc.

I plan to spend more time on this during the holidays.