nasm-devel

[Nasm-devel] Xeon Phi

[William C. <Wil...@gl...>]

Hi there I am the chief maintainer of the Vector Pascal compiler which uses Nasm as its preferred back end.
I am keen to have a version of the compiler out for the Xeon Phi as soon as I can get hold of a Xeon Phi board. It would be a big help if the Nasm team plan to release a Xeon Phi upgrade since otherwise I will be forced into the undocumented purgatory of the Gnu Assembler.

Are there any such plans?

Re: [Nasm-devel] Xeon Phi

[Peter J. <pe...@to...>]

On Mon, 24 Sep 2012, William Cockshott wrote:
> Hi there I am the chief maintainer of the Vector Pascal compiler which uses Nasm as its
> preferred back end. I am keen to have a version of the compiler out for the Xeon Phi as
> soon as I can get hold of a Xeon Phi board. It would be a big help if the Nasm team
> plan to release a Xeon Phi upgrade since otherwise I will be forced into the
> undocumented purgatory of the Gnu Assembler.

I've been looking at adding support for Knights Corner (KNC, Xeon Phi) to 
Yasm, but when I asked Intel about it, the response I received was that 
Intel has not committed to maintaining the instruction encodings.  It's 
hard to know if they can't commit right now because that triggers 
cross-licensing arrangements, or whether they really plan on changing the 
encodings in the near future.

As far as I can tell, GAS doesn't even have support for it yet (at least 
in official CVS).

-Peter

Re: [Nasm-devel] Xeon Phi

[Cyrill G. <gor...@op...>]

On Mon, Sep 24, 2012 at 07:23:41PM +0000, William Cockshott wrote:
> Hi there I am the chief maintainer of the Vector Pascal compiler which uses Nasm as its preferred back end.
> I am keen to have a version of the compiler out for the Xeon Phi as soon as I can get hold of a Xeon Phi board.
> It would be a big help if the Nasm team plan to release a Xeon Phi upgrade since otherwise I will be
> forced into the undocumented purgatory of the Gnu Assembler.
> 
> Are there any such plans?

As Peter mentioned, ineed the encoding is not yet well established. But we have
a plan to support it somewhere in future. No dates though.

	Cyrill

Re: [Nasm-devel] Xeon Phi

[William C. <Wil...@gl...>]

The manuals for the encoding are out I have just printed them out.
________________________________________
From: Cyrill Gorcunov [gor...@gm...] on behalf of Cyrill Gorcunov [gor...@op...]
Sent: Tuesday, September 25, 2012 7:46 AM
To: William Cockshott
Cc: nas...@li...
Subject: Re: [Nasm-devel] Xeon Phi

On Mon, Sep 24, 2012 at 07:23:41PM +0000, William Cockshott wrote:
> Hi there I am the chief maintainer of the Vector Pascal compiler which uses Nasm as its preferred back end.
> I am keen to have a version of the compiler out for the Xeon Phi as soon as I can get hold of a Xeon Phi board.
> It would be a big help if the Nasm team plan to release a Xeon Phi upgrade since otherwise I will be
> forced into the undocumented purgatory of the Gnu Assembler.
>
> Are there any such plans?

As Peter mentioned, ineed the encoding is not yet well established. But we have
a plan to support it somewhere in future. No dates though.

        Cyrill

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.

Re: [Nasm-devel] Xeon Phi

[H. P. A. <hp...@zy...>]

On 09/25/2012 03:40 AM, anonymous coward wrote:
>
> 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]).
>
Hi...

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

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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.