RVA of second section is 200h so it might not work on 9x
Here is version with RVA 1000h
Here is version with RVA 1000h
hi The Svin :D
can u explain why opcode 0F has 256 diff instructions ?...seems that parsing 0x0F
is a double work (as this is the last opcode i need to do now)..
?0F 0000 SLDT WORD PTR DS:?
?0F 0001 SLDT WORD PTR DS:?
?0F 0002 SLDT WORD PTR DS:?
?0F 0003 SLDT WORD PTR DS:?
?0F 0004 00 SLDT WORD PTR DS: ; SIB?
?0F 0005 00000000 SLDT WORD PTR DS:[00000000]?
..
..
this is only 0F 0000 set from until 0F 00FF ... geesh
not mention 0F 0100..
i wonder how the cpu just doesn't *puke* :D
alot of 1 byte F0 XX are invalid...
why intel changed it that way?
normally we dont have a followed Byte for instructions like those..
i.e:
00401000 FE00 INC BYTE PTR DS:
00401002 0F0000 SLDT WORD PTR DS:
i can't really pin point why intel added followed byte , this opcode bugs me :)
can u explain why opcode 0F has 256 diff instructions ?...seems that parsing 0x0F
is a double work (as this is the last opcode i need to do now)..
?0F 0000 SLDT WORD PTR DS:?
?0F 0001 SLDT WORD PTR DS:?
?0F 0002 SLDT WORD PTR DS:?
?0F 0003 SLDT WORD PTR DS:?
?0F 0004 00 SLDT WORD PTR DS: ; SIB?
?0F 0005 00000000 SLDT WORD PTR DS:[00000000]?
..
..
this is only 0F 0000 set from until 0F 00FF ... geesh
not mention 0F 0100..
i wonder how the cpu just doesn't *puke* :D
alot of 1 byte F0 XX are invalid...
why intel changed it that way?
normally we dont have a followed Byte for instructions like those..
i.e:
00401000 FE00 INC BYTE PTR DS:
00401002 0F0000 SLDT WORD PTR DS:
i can't really pin point why intel added followed byte , this opcode bugs me :)
can u explain why opcode 0F
has 256 diff instructions ?...seems that parsing 0x0F
If understand you right, the explonation is
a simple one.
They want to implement new set of instructions
yet they didn't have enough free values to
implement it as byte.
Some values could not be used in code byte -
'cause they used for prefixes,
and among free ones were just a few.
So they decide to pick up one of them 0F
and used it as sign of new set, so that
when decode sees OF it knows that next
byte is one from new set, not old set,
and interpret it in a new way.
For example in your example:
0F0000 SLDT WORD PTR DS:
In this opcode presence of 0F says
that code ID (opcode) is next byte (00)
and processor should take meaning of
00 from new instruction set.
without 0F (take it "sign of new opcodes set")
00 00 would mean:
000000 0 0 00 000 000
add d w(b)[eax] al
add [eax],al
Presence of 0F force processor treat it
as instruction of "new set"
where
00000000 - group ID of several ops and instruction ID
is in cod/r field (000) that format is tipical for
1 operand instructions, and if you study muldivop.exe
you should know this format.
Find muldivop programm and study it
0F 00 00 has the same format logic, the only difference
is that it is from "new" set and has additinal "new
set ID byte" before real opcode - 0F.
thnx the svin :) for the explanation, now i know why Intel has uses 0F for :).
i know it follows the same logic for decoding but for not all the instructions follows it
i will build up an table .
thnx for now :)
:alright:
i know it follows the same logic for decoding but for not all the instructions follows it
i will build up an table .
thnx for now :)
:alright:
How to avoid the "garbage" after dos stub and PE header
produced by MS linker ver.7.10.2179
0045E564: E8C7A6FFFF call .000458C30
0045E569: 8B8D34020000 mov ecx,[00000234]
0045E56F: 03C8 add ecx,eax
0045E571: 8944242C mov [2C],eax
0045E575: 898D38020000 mov [00000238],ecx
0045E57B: FF15BC124000 call _tzset ;MSVCR71.dll
just substitute 03C8 (add ecx, eax) with two nops (9090)
produced by MS linker ver.7.10.2179
0045E564: E8C7A6FFFF call .000458C30
0045E569: 8B8D34020000 mov ecx,[00000234]
0045E56F: 03C8 add ecx,eax
0045E571: 8944242C mov [2C],eax
0045E575: 898D38020000 mov [00000238],ecx
0045E57B: FF15BC124000 call _tzset ;MSVCR71.dll
just substitute 03C8 (add ecx, eax) with two nops (9090)
heya TheSvin,
i was wondering something, i see some disasm engines who decodes (i.e: ida,w32dasm):
69 / r iw IMUL r16,r/ m16,imm16
69 / r id IMUL r32,r/ m32,imm32
like this: imul <reg-mem>,<imm32/16>
but than on the other hand other engines which decode like this:
imul <reg>,<reg-mem>,<imm32/16>
with the same opcode!
i.e: 6900 12345678 - IMUL EAX,DWORD PTR DS:,78563412 - Olly
IMUL EAX, 78563412 - others
when tracing in olly it seems to be doing the same operation as imul <reg-mem>,<imm32/16> .. (which in fact suppose to the the exact same operation...(?))
but than what would be the proper assembly line ?
regards.
i was wondering something, i see some disasm engines who decodes (i.e: ida,w32dasm):
69 / r iw IMUL r16,r/ m16,imm16
69 / r id IMUL r32,r/ m32,imm32
like this: imul <reg-mem>,<imm32/16>
but than on the other hand other engines which decode like this:
imul <reg>,<reg-mem>,<imm32/16>
with the same opcode!
i.e: 6900 12345678 - IMUL EAX,DWORD PTR DS:,78563412 - Olly
IMUL EAX, 78563412 - others
when tracing in olly it seems to be doing the same operation as imul <reg-mem>,<imm32/16> .. (which in fact suppose to the the exact same operation...(?))
but than what would be the proper assembly line ?
regards.
.. (which in fact suppose to the the exact same operation...(?))
imul eax, eax, 8 = imul eax, 8
:confused: small question guys.
About the (d) bit in the byte. Can some1 clarify its use to me??
In an instruction like:
Why the bit (d) is different?? Maybe i missed sth!
cya
CuTedEvil
About the (d) bit in the byte. Can some1 clarify its use to me??
In an instruction like:
mov reg32, imm32
mov imm32, reg
sub reg32, imm32
sub imm32, reg32Why the bit (d) is different?? Maybe i missed sth!
cya
CuTedEvil
The format for sub is 001010:d:w followed by modrm.
The d flag tells opcode decode which is the destination and which is the source (I think). If d bit is set, the destination is register and the source is mem/reg. If d bit is not set, the destination is the mem/reg while the source is reg.
I think The Svin had explained it pretty well.
The d flag tells opcode decode which is the destination and which is the source (I think). If d bit is set, the destination is register and the source is mem/reg. If d bit is not set, the destination is the mem/reg while the source is reg.
I think The Svin had explained it pretty well.
@roticv: I know wut u said, plz read next
Did u get wut i mean??
When can i say that: bit d = 1 = imm32 --> reg32 or vice versa?
CuTedEvil
d = (0) == reg32 --> imm32 (right?)
00401000 > A1 00000000 mov eax, dword ptr ds:[0] 101000(0)1
00401005 A3 00000000 mov dword ptr ds:[0], eax 101000(1)1
d = (1) == reg32 --> imm32 (right?)
0040100A 2B05 00000000 sub eax, dword ptr ds:[0] 001010(1)1
00401010 2905 00000000 sub dword ptr ds:[0], eaxDid u get wut i mean??
When can i say that: bit d = 1 = imm32 --> reg32 or vice versa?
CuTedEvil
I don't quite understand your question.
If bit w is set, means reg32 and mem/reg32
If bit w is set and prefix 66h is present, means reg16 and mem/reg16
If bit w is not set, means reg8 and mem/reg8
For modrm and immediate, it is another opcode, where there is no d bit, but there is s bit. If s bit is set, means that the immediate is "full" size. If s bit is not set, means that the immediate is 1 byte in size.
They come in the format (for add/or/adc/sbb/and/sub/xor/cmp),
100000:s:w
Followed by a "modified" modrm, or with its reg part used to tell which of the 8 opcode is it (/d = /digit)
xx:/d:xxx
And followed by immediate (size indicated by s bit and w bit)
If bit w is set, means reg32 and mem/reg32
If bit w is set and prefix 66h is present, means reg16 and mem/reg16
If bit w is not set, means reg8 and mem/reg8
For modrm and immediate, it is another opcode, where there is no d bit, but there is s bit. If s bit is set, means that the immediate is "full" size. If s bit is not set, means that the immediate is 1 byte in size.
They come in the format (for add/or/adc/sbb/and/sub/xor/cmp),
100000:s:w
Followed by a "modified" modrm, or with its reg part used to tell which of the 8 opcode is it (/d = /digit)
xx:/d:xxx
And followed by immediate (size indicated by s bit and w bit)
imul eax, eax, 8 = imul eax, 8
yeah, thats what i was thinking..prolly intel made it like that to make it easier for programmers to code.
CutedEvil,
thats the format u need to follow.
MOV:
A3 - (101000)[1][1] - mem,acc ; d=1 (direction ->)
A1 - (101000)[0][1] - acc,mem ; d=0 (direction <-)
SUB
2B - (001010)[1][1] [oo][rrr][mmm] - reg,mem ; d=1 (direction <-)
29 - (001010)[0][1] [oo][rrr][mmm] - mem,reg ; d=0 (direction ->)
thats the format u need to follow.
:alright: Got it
For some zen-meditation - fist 4 16bit mode pointers :)
Yan came back from vacation and suggested to change disign.
Here is his version with a new design
Here is his version with a new design
Yan added rest 4 codes for 16bit memory pointers
Here is a long ago promissed artical about
16bit address mode coding.
Two educational apps were sent before.
Zip file contains two OEM font files.
One in English, other - in Russian.
Edit:
See attach in later post
16bit address mode coding.
Two educational apps were sent before.
Zip file contains two OEM font files.
One in English, other - in Russian.
Edit:
See attach in later post
hi theSvin,
i see allot of ?????? ????? ?????? ?????? ??????????? ?? ?????, ??? ????????? ???????? ??
in the english doc, no metter the font.
i see allot of ?????? ????? ?????? ?????? ??????????? ?? ?????, ??? ????????? ???????? ??
in the english doc, no metter the font.
I had the same problem, when I opened it with MS word, it suggested the font (Cyrillic (DOS)) and the strange chars appears to be in a different language.. russian? :confused:
Why they exist in the english doc?
CuTedEvil
Why they exist in the english doc?
CuTedEvil