Re: [Nasm-devel] Xeon Phi

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

> But we have a plan to support it somewhere in future. No dates though.

I have been experimenting with a prototype
implementation that supports the following:

- K1OM instructions
- support for K1OM to [CPU] and CPU
- support for __CPU_K1OM__
- MVEX.R and MVEX.V prefixes (to force unused bits to 1)
- ZMM0...ZMM31 registers (including VSIB)
- K0...K7 mask registers
- disp8*N displacements
- operand modifiers -- {transform} ( op {eviction hint} ) {mask}
- ZWORD operand size qualifier
- ZWORD segment alignment argument
- DZ and RESZ pseudo instructions
- DZ and __DZ__ standard macros
- XITEMZ optional standard macro

The sanity checking for the {...} modifiers is
somewhat tedious, but doable.

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

And yes, I share everyone's concerns about
whether K1OM will persist, or simply be yet
another one-off like L1OM. It's up to Intel, to
provide clarity on that front first.