Intel® ISA Extensions
Use hardware-based isolation and memory encryption to provide more code protection in your solutions.
The Intel sign-in experience has changed to support enhanced security controls. If you sign in, click here for more information.
1078 Discussions

No explanation of comparison codes for integer vector compare instructions


In the ISE document 319433-022, instructions such as VPCMPD refer to an imm8 operand as a comparison predicate.  However, there is no explanation of the values of the predicate.

The Operation section of the instruction doc does indicate the 8 values of the low 3 bits.  But I only noticed this by chance.  It would be nice to have something in the Description section to refer the reader to the details.  Actually, why not use a similar language to that for VCMPPS, etc.

By the way, GNU objdump disassembles 3 and 7 as the immediate bytes by simply showing the value of the byte, rather than using an alias mnemonic such as vpcmpeqd.

Also, since the 5 high bits of the imm8 are specified as reserved, it is not clear whether the processor will ignore a non-zero setting of these bits, or whether it will #UD.  There is nothing in the Exception Conditions table about it.  But it seems that if the processor doesn't enforce the reserved bits being zero, then you won't be able to add nonzero values in a later processor and maintain backward compatibility.

Thus, as a standard specification, I think it should specify the exact behavior of any non-zero reserved bits being set.  If this is actually specified somewhere else in the document, then please add a reference to this in the Description section.


0 Kudos
3 Replies

As you say, the operation section pseudocode shows the operation of the 8 values of the imm8 that that instruction uses.  My personal style is to only list stuff once. Fewer things to fix when I make a mistake. But I did not write that section.

Values 3 and 7 ( false and true) are kind of unusual; If I had to guess, possibly  the implementers of gnu binutils did not feel the need to make pseudo-ops for them.

We do list the upper 5b in the imm8 as reserved but as one can easily tell, we do not #UD when they are nonzero.  That does make it riskier  to consider using them for future expansion. I believe this is true for all imm8, at least in the vector ISA.


Shouldn't there be a policy in these documents that whenever something is indicated as 'reserved', then it should specify the value (usually 0) AND the processor should #UD if the reserved value is not coded.  And conversely, if the processor accepts any value, then it should be indicated as 'ignored' rather than 'reserved'.

If you agree, then the doc needs to be corrected one way or the other, since it is currently inconsistent.

Could you check that the processor does indeed accept any value for these upper 5 bits.  I'll try it with the software emulator when I get around to it and post the result.  However, I wouldn't want to use the emulator as the definitive standard for the processor behavior, and it would be best to test it on an actual processor.

Finally, could you forward this posting to your documentation team.  Including the suggestion about having a reference to a table of the imm8 values.  Thanks.


Black Belt

>>My personal style is to only list stuff once. Fewer things to fix when I make a mistake. (Mark)
>> having a reference to a table of the imm8 values. (Michael)

There is no reason in this day and age of HTML documents that a document writer cannot write a table once, and include at least a hyperlink wherever referenced. However, I favor Michael's request that a copy be placed at the point of reference. This too can now be done using HTML (one copy of the text is in the document but it appears in multiple places when viewed).

Jim Dempsey