Olly and test

[Vortex]

Hi Paulo,

The output matches the source code, no?

[dedndave]

Vortex -
Functionally, it does - Olly seems to swap the destination and source registers in the text listing
Odd that it does this on instructions where it does not matter, but gets them right when it does matter

[BlackVortex]

Vortex -
Functionally, it does - Olly seems to swap the destination and source registers in the text listing
Odd that it does this on instructions where it does not matter, but gets them right when it does matter

Are you sure it's Olly ?  I'm not on my development machine so I can't assemble the test case, but try with another disassembler, I suggest Hdasm (freeware) or Hiew (limited trial)

I'm surprised you haven't tried another disassembler already !

[dedndave]

well, JJ checked the op-codes against references
so - must be Olly
it was confirmed by others, as well

[jj2007]

well, JJ checked the op-codes against references
so - must be Olly
it was confirmed by others, as well

I am not so sure - see Paulo's post at the end of page 1. He tried goasm and found the same order in Olly. So there are two possibilities:
1. goasm and olly have the same bug
2. masm is buggy

Based on my long-standing experience with Microsoft (TM) products, I tend to favour option 2 :toothy

[dedndave]

Normally, I might agree with you JJ.
But MASM gets those codes from a table.
they get certain bits of the second byte for the destination register and certain bits for the source register and OR them together
They use the same tables for some of the other instructions where it would make the code not work.

I am guessing here - the GoAsm guys used Olly as an opcode reference ?

I went back to the old 16 bit op-codes
they will be AX and CX instead of EAX and ECX, of course
but, this way, both MASM and Olly are eliminated from the equation

85C1  TEST CX,AX
85C8  TEST AX,CX

using good old 16-bit MS (XP version) debug that we all know and trust, it is backwards, also - lol
here is how you can tell for sure
instead of using the TEST instruction, use XCHG (i have been trying to get someone to try it - no luck - i do not have Olly installed)
the reason is, XCHG AX,CX is a special one-byte form (or XCHG EAX,ECX)
XCHG CX,AX is a two-byte form (or XCHG ECX,EAX)
you will know for sure right away if the source/destination registers are swapped, by the length of the op-code

using MS (xp ver) debug i did this....
91    XCHG CX,AX (we know this is reversed because XCHG CX,AX is two bytes)
87C1 XCHG AX,CX
87C8 XCHG CX,AX

next test.........
i dug up my old fave SymDeb - the c/l symbolic debugger that came with MASM 5.1
91     XCHG AX,CX
87C1 XCHG AX,CX
87C8  XCHG CX,AX


you will not be able to code XCHG CX,AX with MASM because it optimizes it into 1-byte (at least, it's supposed to)
but......
db 91h
db 87h,0C1h
db 87h,0C8h
then look at it with Olly


I have the Intel Manual right here
it is about as clear as mud
I am trying to decode it................

[PauloH]

Hi guys.
I tried the IDA disassembler, freeware edition and the results are changed too... the masm output matches the source code and the goasm output doesn't!!!
The attached files have .jpg files with the results. There are the sources I have used.
The confusion grows a little.
Kind regards.

[attachment deleted by admin]

[redskull]

It's a bug in masm.  As per the Intel manual, TEST ecx, eax is:

TEST r/m32, r32 should encode to 85 /r

where /r is

mod (11), reg32 (000), and r/m32 (001).  You put them together and get C1 for the second byte, which MASM encodes as C8 (and vice versa for the other way).  This comes from volume 2A, table 2-2 (though my intel manual is old) and figure 2-1.  Just to verify it:


From MASM:

Code Select Expand


00000001  85 C8   test ecx, eax   ; ecx in front
00000003  85 CB   test ecx, ebx
00000005  85 CA   test ecx, edx
00000007  85 CF   test ecx, edi
00000009  85 CE   test ecx, esi
0000000B  85 CD   test ecx, ebp
0000000D  90   nop
0000000E  85 C1   test eax, ecx   ; ecx behind
00000010  85 D9   test ebx, ecx
00000012  85 D1   test edx, ecx
00000014  85 F9   test edi, ecx
00000016  85 F1   test esi, ecx
00000018  85 E9   test ebp, ecx

from NASM

Code Select Expand


    26 0000000E 85C1                      test ecx, eax   ; ecx in front
    27 00000010 85D9                      test ecx, ebx
    28 00000012 85D1                      test ecx, edx
    29 00000014 85F9                      test ecx, edi
    30 00000016 85F1                      test ecx, esi
    31 00000018 85E9                      test ecx, ebp
    32 0000001A 90                        nop
    33 0000001B 85C8                      test eax, ecx   ; ecx behind
    34 0000001D 85CB                      test ebx, ecx
    35 0000001F 85CA                      test edx, ecx
    36 00000021 85CF                      test edi, ecx
    37 00000023 85CE                      test esi, ecx
    38 00000025 85CD                      test ebp, ecx

Olly is right, MASM generates the wrong opcodes.  Of course, since it just AND's then together, they're functionally equivalent (I think)

-ac

[PauloH]

This is the file with goasm output.


[attachment deleted by admin]

[dedndave]

thanks Paulo and RedSkuill - lol
i could not find the field definitions - i hate reading out of PDF's
it makes me wonder how they put AND together without trouble
MASM must be a box of band-aides - lol

[BlackVortex]

So the moral of the story is that an assembler may lie, but a disassembler ... NEVER !!!

Right ?  :green2

[dedndave]

lol - you have a point, there
the guys that take stuff apart are more intense about getting it right than the ones that put it together

the moral of the story is
Billy Gates lies as well as politicians

the one MS group i trusted was the assembler guys
my innocence is gone, now  :(

on the bright side, nice to see that Olly and the GoAsm guys are on their toes   :U

[jj2007]

my innocence is gone, now  :(

It's never too late, Dave :wink

I like Masm. It's a bad-mannered animal, but its macro capabilities are a strong point. You can write your own version of Fortran, Basic or Perl, and its pure Masm - M for macro, but the code is assembler...

Kudos to the guys who designed Masm, in case they are still around.

[dedndave]

i haven't used macros much at all
except - long ago, i wrote a math library for 8088 with no 8087
for that, i used macros and a lot of conditional assembly for the different memory models
i think it was more of a lesson in MASM than math
i have forgotten all that stuff

you would think that, with my experience with ASM, it would be easy to learn 32-bit
but, i am struggling with
all the new pentium instructions
all the new MASM directives
learning Windows API, etc

yah - i think that's just everything - lol

i feel sorry for those who are trying to learn assembler anew
it was much easier in the 8088 days

[Jimg]

My reading of the instruction definition says masm and debug are right, and olly is wrong, despite how redskull interpreted it.