RVA of second section is 200h so it might not work on 9x
Here is version with RVA 1000h
Posted on 2003-08-05 05:01:09 by The Svin
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 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..
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 :)
Posted on 2003-08-07 13:08:43 by wizzra

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:

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"
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.
Posted on 2003-08-07 13:48:40 by The Svin
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 :)
Posted on 2003-08-07 13:56:35 by wizzra
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)
Posted on 2003-08-08 13:45:56 by lingo12
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 ?
Posted on 2003-08-08 18:40:27 by wizzra
.. (which in fact suppose to the the exact same operation...(?))

imul eax, eax, 8 = imul eax, 8
Posted on 2003-08-08 21:39:03 by roticv
:confused: small question guys.

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, reg32

Why the bit (d) is different?? Maybe i missed sth!

Posted on 2003-08-09 03:23:35 by 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.
Posted on 2003-08-09 03:34:47 by roticv
@roticv: I know wut u said, plz read next

 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], eax

Did u get wut i mean??

When can i say that: bit d = 1 = imm32 --> reg32 or vice versa?

Posted on 2003-08-09 03:43:04 by 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),
Followed by a "modified" modrm, or with its reg part used to tell which of the 8 opcode is it (/d = /digit)
And followed by immediate (size indicated by s bit and w bit)
Posted on 2003-08-09 03:53:39 by roticv

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.
Posted on 2003-08-09 04:08:36 by wizzra

A3 - (101000)[1][1] - mem,acc ; d=1 (direction ->)
A1 - (101000)[0][1] - acc,mem ; d=0 (direction <-)

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.
Posted on 2003-08-09 04:37:36 by wizzra
:alright: Got it
Posted on 2003-08-09 17:07:47 by CuTedEvil
For some zen-meditation - fist 4 16bit mode pointers :)
Posted on 2003-08-22 12:47:12 by The Svin
Yan came back from vacation and suggested to change disign.
Here is his version with a new design
Posted on 2003-08-22 14:02:56 by The Svin
Yan added rest 4 codes for 16bit memory pointers
Posted on 2003-08-24 04:44:52 by The Svin
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.
See attach in later post
Posted on 2003-10-08 04:33:21 by The Svin
hi theSvin,

i see allot of ?????? ????? ?????? ?????? ??????????? ?? ?????, ??? ????????? ???????? ??
in the english doc, no metter the font.
Posted on 2003-10-08 05:13:46 by wizzra
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?

Posted on 2003-10-08 06:12:53 by CuTedEvil