Hello fellows.
I have a question again.
In MS VC++ 2005 there is a pseudo instruction _emit, used in __asm block. msdn states it is like DB in masm.
i wanted the following to become nop
yet the result was quite different:
so what should i do?
I have a question again.
In MS VC++ 2005 there is a pseudo instruction _emit, used in __asm block. msdn states it is like DB in masm.
i wanted the following to become nop
__asm _emit 0x90yet the result was quite different:
DB -112 ; ffffff90Hso what should i do?
emit 0x90909090 :)
Doesn't look wrong to me.
DB -112 is the same as DB 90h (interpreting 90h as a signed byte, expressed in decimal).
Sign-extending 90h to a 32-bit value yieds FFFFFF90h.
DB -112 is the same as DB 90h (interpreting 90h as a signed byte, expressed in decimal).
Sign-extending 90h to a 32-bit value yieds FFFFFF90h.
Thats right, it works fine.
but in asm listing it transforms mysteriously (bug?) to signed 32 bit aligned value.
which is not a hex instruction.
thanks guys.
but in asm listing it transforms mysteriously (bug?) to signed 32 bit aligned value.
which is not a hex instruction.
thanks guys.
'emit' just emits a byte, just like db.
It isn't an instruction, it's a byte.
It also doesn't 'transform' to 32-bit, because it says db. It would say dd if it were 32-bit.
The only thing is that the comment it places behind it (see ';'), is a 32-bit signed interpretation of the number -112. It's just a comment, so just ignore it.
It does exactly what it says on the tin.
It isn't an instruction, it's a byte.
It also doesn't 'transform' to 32-bit, because it says db. It would say dd if it were 32-bit.
The only thing is that the comment it places behind it (see ';'), is a 32-bit signed interpretation of the number -112. It's just a comment, so just ignore it.
It does exactly what it says on the tin.
It isn't an instruction, it's a byte.
It also doesn't 'transform' to 32-bit, because it says db. It would say dd if it were 32-bit.
The only thing is that the comment it places behind it (see ';'), is a 32-bit signed interpretation of the number -112. It's just a comment, so just ignore it.
It does exactly what it says on the tin.
anyway it should say db 90h in listing, it doesn't so its a bug in MS VC 2005 listing generation (not in code).
because -112 is not 1 byte but 4.
it does exactly what it says on the tin, right.
but the picture on the cover don't mach with whats inside; )))
anyway it should say db 90h in listing, it doesn't so its a bug in MS VC 2005 listing generation (not in code).
because -112 is not 1 byte but 4.
Why would -112 be 4 bytes?
It says db, so it can only emit 1 byte, and -112 can perfectly fit in one byte, in which case the hexadecimal representation is 90h.
There's no bug.
If you were to write __emit -112, you'd see the same thing.
Turnip, Scali is right. 0x90 (hex) = -112 (signed) = 144 (unsigned).
A byte can be one of 256 values. An unsigned byte can be anywhere from 0 to 255. A signed byte can be anywhere from -128 to 127.
The listing says DB -112, because it is assuming a negative number due to the fact that the MSB is set, in which is the qualifier for a number to be negative. If the listing is providing a comment of ; ffffff90H for that instruction, ignore it and write it off as lazy programming for carrying out the sign bit to a full DWORD value.
Read up on two's complement and the like, it should help you out.
A byte can be one of 256 values. An unsigned byte can be anywhere from 0 to 255. A signed byte can be anywhere from -128 to 127.
The listing says DB -112, because it is assuming a negative number due to the fact that the MSB is set, in which is the qualifier for a number to be negative. If the listing is providing a comment of ; ffffff90H for that instruction, ignore it and write it off as lazy programming for carrying out the sign bit to a full DWORD value.
Read up on two's complement and the like, it should help you out.