This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ENTER/BOUND operands order.

Hi, Michael

Dnia 2014-01-16 17:48 Michael Zolotukhin napisaÅ(a):
>> Is there anything supporting this view of yours?
>I will recheck it with the document authors and get back to you.
>> That would be very odd: Tests setting language standards. If you
>> don't take the Intel manual as sufficient reference, the next best
>> thing setting a standard here is MASM. Did you check how they
>> require the operands to be ordered?
>No, I didn't. I don't think MASM is a reference here either though, as
>it is another asm. But I agree that there could me much confusion with
>this syntax, and in future it should be either explicitly specified in
>the instructions documentation, or in a separate document.

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. There is also a lot of examples which describe 
various forms of instructions encoding and location of these flags. For 

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}

Maybe the version of the reference manual is the case. I use 319433-17.pdf.

SÅawomir Wojtasiak

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]