This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: ENTER/BOUND operands order.
- From: "Michael V. Zolotukhin" <michael dot v dot zolotukhin at gmail dot com>
- To: S??awomir Wojtasiak <slawomir dot wojtasiak at swksoftware dot pl>
- Cc: "\"Jan Beulich\"" <jbeulich at suse dot com>, "\"H.J. Lu\"" <hjl dot tools at gmail dot com>, "\"binutils at sourceware dot org\"" <binutils at sourceware dot org>
- Date: Fri, 17 Jan 2014 11:01:50 +0400
- Subject: Re: ENTER/BOUND operands order.
- Authentication-results: sourceware.org; auth=none
- References: <3482868a668de8ebe53975eb7d79d725 dot qmail at home dot pl> <b4fcb2a62aa358bc134689ccd33eebcb dot qmail at home dot pl> <52D7A465020000780011423E at nat28 dot tlf dot novell dot com> <CANtU078BKxoUiKdmqp8ii0TFvi2T1itzzn7dicQoAbKzdwtRmg at mail dot gmail dot com> <52D807FE02000078001144A2 at nat28 dot tlf dot novell dot com> <CANtU07-s=VXv2yCb2FA_Dyco14d5LiC4of7r7zCkNa+4_omFxg at mail dot gmail dot com> <52D80C8402000078001144D5 at nat28 dot tlf dot novell dot com> <9f1ffd59bc7111c4ba411898a840f1c6 dot qmail at home dot pl>
Hi Jan, Slawomir,
> Unfortunately as Jan said, these instructions seem to be broken. Intel
> manual is pretty accurate about the syntax of EVEX-encoded instructions.
> Unit tests can not prove anything in this specific case. Opmask registers as
> well as EVEX flags are encoded using these braces located directly next to
> the instruction operands.
That's not it. As I said, the document only expresses required elements that an
assembler could implement. Whether to treat it as an ASM syntax operand is
purely a SW tool implementation choice, as is the placement of such a modifier.
How a parser chooses to accept token definitions for this element is another
implementation detail for the tool implementer and doesn't belong in this
document. That's almost a quote from the document's author.
Thus, order of operands is implementation dependent, and for GAS it is the
following: RC/SAE operand goes between SIMD-operand and non-SIMD operand (or
after SIMD-operand if there is no non-SIMD one). That was suggested when the
patch was sent (in July'13), and there were no objections to it. Now it is
already in binutils 2.24, and there is nor reason neither possibility to change
it. And even if it was committed yesterday, what would be a good reason to just
reorder operands?
> There is also a lot of examples which describe
> various forms of instructions encoding and location of these flags. For
> instance:
>
> ***
> Additionally, the EVEX encoding scheme of AVX-512 Foundation can express
> conditional vector addition as
> VADDPS zmm1 {k1}{z}, zmm2, zmm3
> ***
>
> ****
> "An example of use would be in the following instructions:
> vaddps zmm7 {k6}, zmm2, zmm4, {rd-sae}"
> ****
>
> ****
> ; instructions with memory operands
> vmulps zmm7 {k6}, zmm2,[rax], {rd-sae}
> ****
These examples don't specify assembler syntax, though GAS accepts them as is, as
they obey the GAS operands order I described above.
> Maybe the version of the reference manual is the case. I use 319433-17.pdf.
I looked at 319433-15, but for our case that seems not to matter.
Thanks,
Michael