Hey all.
After a long hiatus I've come back to my assembler, and am (still) encoding MOV :)
I'm up to the last section though, and after this I am sure encoding becomes much quicker (once I've got the hang of effective addressing, and I think I have!).
My question: the Intel x86 manual says this:
So, why isn't this type of instruction possible?
Thanks.
After a long hiatus I've come back to my assembler, and am (still) encoding MOV :)
I'm up to the last section though, and after this I am sure encoding becomes much quicker (once I've got the hang of effective addressing, and I think I have!).
My question: the Intel x86 manual says this:
C7 /0 MOV r/m32,imm32 Move imm32 to r/m32
So, why isn't this type of instruction possible?
mov [esp+ecx*2], 0FFh
mov [esp+ecx*2], eax ; Assembles just fine.
Thanks.
Should be:
mov byte ptr , 0FFh
The problem is not in the encoding but in the syntax MASM expects you to use. :)
mov byte ptr , 0FFh
The problem is not in the encoding but in the syntax MASM expects you to use. :)
It's also ambiguous.
Which does it mean?
mov byte ptr ,0ffh
mov word ptr ,0ffh
mov dword ptr ,0ffh
They are all valid.
Which does it mean?
mov byte ptr ,0ffh
mov word ptr ,0ffh
mov dword ptr ,0ffh
They are all valid.
Lol.. thanks. A simple oversight of course :)
tenkey: What would be the difference between the types in terms of encoding? The ModR/M byte would hold a different R/M field (DispByte or DispDWord)?
tenkey: What would be the difference between the types in terms of encoding? The ModR/M byte would hold a different R/M field (DispByte or DispDWord)?
Nevermind, a little inspection of disassembled MASM reveals all. Aw man, just when I thought it was getting easy - now I have to look at prefix bytes.. :)
i can also recommend using hiew while dealing with assembling opcodes and such (or another tool that allows you to assemble instructions quickly). you can check and compare things very fast in this way.