NASM manual error?

[nobody]

Frank or Chuck,

I posted the following to alt.lang.asm.  I probably should've posted here since Google Groups hasn't picked it up after 12 hours.

One x86 instruction document I have says SETcc is encoded as:

017 220+CC x0m  setcc Rb

I.e., "0f 90+cc /0".

Trying to find out if /0 was a required part of the instruction or not, I
checked an online document which had no mention of the /0...

I then checked the NASM manuals.  The 0.98.39 and 0.99.0 manuals both say
"0f 90+cc /2":

SETcc r/m8                    ; 0F 90+cc /2          [386]


Eventually, I checked an Intel .pdf, which doesn't list /0 in the main SETcc
section...  However, in the encoding section of an Intel document, it says
this:

SETcc - Byte Set on Condition
    register 0000 1111 : 1001 tttn : 11 000 reg
    memory   0000 1111 : 1001 tttn : mod 000 r/m


I.e., I think the NASM manual should be /0, not /2, as in "0F 90+cc /0"...



Rod Pemberton

(P.S. I'll catch replies to either message.)

[nobody]

The "official" encoding is /0, i.e. modrm.reg=000b.

However, x86 processors do ignore that field for SETcc.

One way to address this situation in an assembler is to
provide SET0cc...SET7cc instructions, i.e. use 0...7 to
select and emit the desired modrm.reg value.

That way you get:

SETcc  (0Fh,9xh,00h...07h)
SET0cc (0Fh,9xh,00h...07h)
SET1cc (0Fh,9xh,08h...0Fh)
SET2cc (0Fh,9xh,10h...17h)
SET3cc (0Fh,9xh,18h...1Fh)
SET4cc (0Fh,9xh,20h...27h)
SET5cc (0Fh,9xh,28h...2Fh)
SET6cc (0Fh,9xh,30h...37h)
SET7cc (0Fh,9xh,38h...3Fh)

SETcc  (0Fh,9xh,40h...47h)
SET0cc (0Fh,9xh,40h...47h)
SET1cc (0Fh,9xh,48h...4Fh)
SET2cc (0Fh,9xh,50h...57h)
SET3cc (0Fh,9xh,58h...5Fh)
SET4cc (0Fh,9xh,60h...67h)
SET5cc (0Fh,9xh,68h...6Fh)
SET6cc (0Fh,9xh,70h...77h)
SET7cc (0Fh,9xh,78h...7Fh)

SETcc  (0Fh,9xh,80h...87h)
SET0cc (0Fh,9xh,80h...87h)
SET1cc (0Fh,9xh,88h...8Fh)
SET2cc (0Fh,9xh,90h...97h)
SET3cc (0Fh,9xh,98h...9Fh)
SET4cc (0Fh,9xh,A0h...A7h)
SET5cc (0Fh,9xh,A8h...AFh)
SET6cc (0Fh,9xh,B0h...B7h)
SET7cc (0Fh,9xh,B8h...BFh)

SETcc  (0Fh,9xh,C0h...C7h)
SET0cc (0Fh,9xh,C0h...C7h)
SET1cc (0Fh,9xh,C8h...CFh)
SET2cc (0Fh,9xh,D0h...D7h)
SET3cc (0Fh,9xh,D8h...DFh)
SET4cc (0Fh,9xh,E0h...E7h)
SET5cc (0Fh,9xh,E8h...EFh)
SET6cc (0Fh,9xh,F0h...F7h)
SET7cc (0Fh,9xh,F8h...FFh)

[nobody]

Let's assume that you're 100% correct and /1 to /7 are both functional and (apparently) undocumented aliases for /0 for the SETcc instruction.

Is there enough justification to add SETcc aliases to an assembler?  I'd say: "No."

1) easily created with an assembler macro
 2) easily created via hex editor
 3) if opcode map changes, could prevent proper dissassembly
 4) don't seem to be documented by Intel, AMD, or reputable source (e.g., Robert Collins)


Are there any uses for SETcc aliases?  I'd say: "Yes."

1) could possibly be used to detect code executing on a cpu versus an emulator
   a) to disable code
      i) work around bugs in emulators: QEMU or Bochs
      ii) that is incompatible with an emulator: unimplemented IDE functions
   b) to prevent code detection, i.e., hide code
      i) virii
      ii) copyrighted
      iii) security
 2) code obfuscation, i.e., prevent correct disassembly
   a) copyrights
   b) security
   c) virii
 3) code steganography (http://www.crazyboy.com/hydan/)


If the functionality of aliases are equivalent by definition, then why use an alias?

"To confuse others" is the primary answer I come up with (others listed above).


Some aliases are well documented and would be justifiable in an assembler or disassembler, but I don't think SETcc is one of them (yet):

1) and/or/adc/sbb/and/sub/xor/cmp 82h for 80h, except AMD64
  2) shl/sal /6 for /4
  3) test f6 /1 for f6 /0
  2) test f7 /1 for f7 /0


Rod Pemberton

[nobody]

> Let's assume that you're 100% correct and /1 to /7 are both
> functional and (apparently) undocumented aliases for /0 for
> the SETcc instruction.

I have helped build x86 chips for a living.

But hey, feel free to verify this behavior yourself.  :)

> Is there enough justification to add SETcc aliases to an
> assembler? I'd say: "No."
>
>     1) easily created with an assembler macro

I'd love to see your macro.

Because I don't think that the "stock" NASM preprocessor is
capable enough to implement full effective address support.

>     2) easily created via hex editor

I prefer assembling to binary patching.

>     3) if opcode map changes, could prevent proper dissassembly

It won't change. (That would break x86 compatibility.)

>     4) don't seem to be documented by Intel, AMD, or reputable source (e.g., Robert Collins)

There are plenty of x86 details that aren't documented any-
where in the public domain.

> Are there any uses for SETcc aliases? I'd say: "Yes."

I concur.

Some people want to emit those encodings. Let them. I don't
really care what their reasons are.

>     1) could possibly be used to detect code executing on a cpu versus an emulator

An emulator that doesn't support them isn't x86-compatible.

Anyway.

I think we are digressing.

I gave you the facts. So my part is done.  :)