On my Prog. Xor ebx,esi is 33 F3 not 31 DE. Can you explain it ? :confused:
Posted on 2003-04-02 08:05:01 by realvampire
D flag

XOR ebx,esi

can be
--------------------------------
001100 11 11 011 110

which is 33 DE

or

001110 01 11 110 011

which is 39 F3

Correct me if i am wrong
Posted on 2003-04-02 08:44:39 by roticv
roticv is absolultly right.
cod/r and mem/r field are containers wich hold operands
and d flag(direction) points wich one of them source and
wich one is destination. So if you swap them and change direction flag - you get the same result.
And latest app focuses on understanding it, as one of educational methods to understand meaning of D flag.
In referece page it even has arrow that show direction.
Changing bit D you change the direction accordinly.

!!!!!
I ask moderators again: delete previous version of the app - I can not do it.
Posted on 2003-04-02 11:17:54 by The Svin

!!!!!
I ask moderators again: delete previous version of the app - I can not do it.

I've got a better idea for the moderators: make the Svin a moderator (in this forum or an special forum for opcodes). :)

the Svin for president! :alright:
Posted on 2003-04-02 13:34:27 by scientica
I hope, we soon finish with opcodes and proceed with
number theory, formats and integer math.
Posted on 2003-04-02 14:10:25 by The Svin
which attachment is it that you need deleted?
You seem to have multiple different ones.
Posted on 2003-04-02 17:24:34 by Hiroshimator
In post where I first asked to delete attachment, attached file mod11b~1.zip, the same mod11b~1.zip was attached
couple posts before.
That previous file needs to be deleted, 'cause has a bug wich was removed it latest attachment.
Posted on 2003-04-02 17:38:41 by The Svin
ok I think I have it.
I'll need to find some sort of better way to deal with attachments :(
Posted on 2003-04-02 17:42:31 by Hiroshimator

In post where I first asked to delete attachment, attached file mod11b~1.zip, the same mod11b~1.zip was attached
couple posts before.
That previous file needs to be deleted, 'cause has a bug wich was removed it latest attachment.


Thats why MS decided to take back all of their product :grin: (Just a Joke). sVin caould you please tell me about Org ?:alright:
Posted on 2003-04-03 17:51:03 by realvampire
It's strange place ask about ORG in the thread
where bit fields of opcode are being discussed.
But I'll try to make related to opcode.
Lemonade from lemon.
ORG is about setting offset counter:

ORG expression
Sets the location counter to expression.

Now how can it be used creating needed opcode
format without totaly writing in hex.
Last artical discussed S bit of code block.
From it is clear (who don't understand about
S bit - please, read the artical before asking questions)
that if value of immediate operand may be
represented in sign byte (-128>=x<=127) opcode
that used the imm. operand may be coded in two
different ways - with S bit = 1 and imm operand block = 1byte
or with S bit = 0 and imm. operand block = full size (in Win32 dword
if prefix 66h is not used)
For example:



83E9 02 SUB ECX,2 ; Code block 83 - s bit = 1
81E9 02 00 00 00 SUB ECX,2 ; Code block 81 - s bit = 0



Assembler always generates optimal version. (In the case - 3 bytes 83E9 02)
So what if we want to force assembler generate 6 byte version,
for example for alignment perpose. But we don't want write everything in hex.
Here is how we can do it :


sub ecx,8888h ; any value that can't be in size of sign byte
org $-4 ;set address counter to start of imm. operand block
dd 2 ;overwrite 00008888h with 00000002h

sub ecx,8888h
will force assemble generate code block with S bit = 0 'cause 8888h
operand exceed limits of signed byte.
Then we set counter on place of 88 88 00 00 generated imm. operand
and replace them with
dd 2 = 02 00 00 00 in bytes.
81E9 02 00 00 00 will be generated.
Posted on 2003-04-04 13:51:31 by The Svin
quick question The Svin,
what bit(s) would tell the reg16/32 in for example those:

00401000 000400 ADD BYTE PTR DS:, AL
00401003 000C00 ADD BYTE PTR DS:, CL
00401006 001400 ADD BYTE PTR DS:, DL
00401009 001C00 ADD BYTE PTR DS:, BL
0040100C 002400 ADD BYTE PTR DS:, AH
0040100F 002C00 ADD BYTE PTR DS:, CH
00401012 003400 ADD BYTE PTR DS:, DH
00401015 003C00 ADD BYTE PTR DS:, BH
--------------------------------------------------------------------
00401000 004000 ADD BYTE PTR DS:, AL
00401003 000C00 ADD BYTE PTR DS:, CL
00401006 001400 ADD BYTE PTR DS:, DL
00401009 001C00 ADD BYTE PTR DS:, BL
0040100C 002400 ADD BYTE PTR DS:, AH
0040100F 002C00 ADD BYTE PTR DS:, CH
00401012 003400 ADD BYTE PTR DS:, DH
00401015 003C00 ADD BYTE PTR DS:, BH
----------------------------------------------------------------------
00401000 008000 ADD BYTE PTR DS:, AL
00401003 000C00 ADD BYTE PTR DS:, CL
00401006 001400 ADD BYTE PTR DS:, DL
00401009 001C00 ADD BYTE PTR DS:, BL
0040100C 002400 ADD BYTE PTR DS:, AH
0040100F 002C00 ADD BYTE PTR DS:, CH
00401012 003400 ADD BYTE PTR DS:, DH
00401015 003C00 ADD BYTE PTR DS:, BH
----------------------------------------------------------------------------

i don't mean the reg+reg, only the [],reg part
i sketched a bits looks: 0000 0000 01 00 00 000 000 (hope fully this is a right one), anyway to determind the reg?
Posted on 2003-04-09 13:54:17 by wizzra
00401000 000400 ADD BYTE PTR DS:, AL
00401003 000C00 ADD BYTE PTR DS:, CL
00401006 001400 ADD BYTE PTR DS:, DL
00401009 001C00 ADD BYTE PTR DS:, BL
0040100C 002400 ADD BYTE PTR DS:, AH
0040100F 002C00 ADD BYTE PTR DS:, CH
00401012 003400 ADD BYTE PTR DS:, DH
00401015 003C00 ADD BYTE PTR DS:, BH
--------------------------------------------------------------------
00401000 004000 ADD BYTE PTR DS:, AL
00401003 000C00 ADD BYTE PTR DS:, CL

00401006 001400 ADD BYTE PTR DS:, DL
00401009 001C00 ADD BYTE PTR DS:, BL
0040100C 002400 ADD BYTE PTR DS:, AH
0040100F 002C00 ADD BYTE PTR DS:, CH
00401012 003400 ADD BYTE PTR DS:, DH
00401015 003C00 ADD BYTE PTR DS:, BH
----------------------------------------------------------------------
00401000 008000 ADD BYTE PTR DS:, AL
00401003 000C00 ADD BYTE PTR DS:, CL
00401006 001400 ADD BYTE PTR DS:, DL
00401009 001C00 ADD BYTE PTR DS:, BL
0040100C 002400 ADD BYTE PTR DS:, AH
0040100F 002C00 ADD BYTE PTR DS:, CH
00401012 003400 ADD BYTE PTR DS:, DH
00401015 003C00 ADD BYTE PTR DS:, BH
----------------------------------------------------------------------------

i don't mean the reg+reg, only the [],reg part
i sketched a bits looks: 0000 0000 01 00 00 000 000 (hope fully this is a right one), anyway to determind the reg?


:confused: I now understand why mommy did not let me subscribe this thread....
Posted on 2003-04-09 17:58:30 by realvampire
heheheheh
well, /me feels sorry over the pentium :)
those basted bits can make ya completely mad :)
hope fully The Svin knows much better to answer my question :D
Posted on 2003-04-10 01:38:34 by wizzra
I'v played abit to find how to get the XX,AL / AL,XX reg bits,
and found it



AL: [0-7]
00 [b]000[/b] 000
00 000 001
00 000 111

CL: [8-F]
00 001 000
00 001 001
00 001 111

DL: [10-17]
00 010 000
00 010 001
00 010 111

BL: [18-1F]
00 011 000
00 011 001
00 011 111

AH: [20-27]
00 100 000
00 100 001
00 100 111

CH: [28-2F]
00 101 000
00 101 001
00 101 111

DH: [30-37]
00 110 000
00 110 001
00 110 111

BH: [38-3F]
00 111 000
00 111 001
00 111 111


it repeats it self over the 0x40-0x80

So basically you come out with this formula:
<D/W> <REG> <ADDRESSING>

(32/16) XX,AL/AL,XX

Those damn bits can give ya allot of headach :P
Posted on 2003-04-12 04:27:25 by wizzra
I already Know it.
Check my tools at The Heap Forum. The thread name is "FARABI is Open Source!Get Here".
What is inside the OBJ file?




Example:
mov eax,ecx ; 8BC0
nop ; 90
nop ;90.



Will it be 8B C0 90 90 in obj file ? :confused:
Posted on 2003-04-12 04:34:23 by realvampire
If I am not wrong, obj have their own file header and stuffs like that including sections.

By the way The Svin, could you explain to me how the processor knows how long is the opcode? ie, how it tells the opcode it is reading is 1 byte or it is 2 byte?
Posted on 2003-04-12 04:43:28 by roticv
wizzra,
First byte - code block.
In second byte (modr/m) - two upper bits - mod, it says if address
address part of opcode has displacment bits and how many of them.
last three bits - mem/r field, it says if there is SIB byte following the
byte(100) then all pointers are in the SIB;
if there is no register pointers just displacement (mod=00 and mem/r =101);
otherwise it has code for register - pointer.
I belive it all is explained it details in this very thread, just read it.
Or you want me decode opcodes in bits reference as an example?
If so - please, choose 2 or 3 of them, I'm lazy to type bit reference
decoding for all in your list, it's too big.

000C00 ADD BYTE PTR DS:, CL

00 0C 00
First byte 00 - code block.
in bits 00000 0 0
code = 00000 - code for add
d = 0 - from code/r to mem/r
w = 0 - size of operand = byte.

Next byte - modr/m
in bit fields 00 001 100
mod = 00 = mem/r has memory operands without
displacement
reg = 001 = CL
mem/r = 100 = SIB is next byte and all memory pointers
in SIB

Last byte - SIB
in bit fields 00 000 000
scale = 00 = x1
index = 000 = eax
base = 000 = eax

Decode second and third byte of each opcode in your
list the same way as I've done above.
If you don't know how to understand values of each bitfield - reread the thread, here is absolutly detailed explonation of meaning of each field and reference of
all values that can be in the fields.

My good friend scientica can easily decode it for you if
there still a problem.
Seems that he is the only one who's read all the text :)
Posted on 2003-04-12 07:20:43 by The Svin

By the way The Svin, could you explain to me
how the processor knows how long is the opcode?
ie, how it tells the opcode it is reading is 1 byte or it is 2 byte?


Do you mean the whole opcode of instruction or just code block?
If code block has 2 bytes first byte if special "set" byte.
There is a few such bytes, and if first byte is not one of them - then
code block is 1 byte size.
Give me some raw opcode, I'll write down how I would determine
its size using human logic, it could help to understand how processor understand it.
General logic is:
1. While byte is prefix - go to next byte.
2. First not prefix byte - start of code block,
check if it is from "new instruction set" (for example if first code block byte 0F etc.)
3. Code block itself assumes operands, if instruction has no operands - finished,
some instruction assumes imm. operand then from s bit processor determines size of it.
(if prefix 66 used it's also counted 'cause it changes size of imm. if s = 0)
4. If code supposed to use modr/m then decoding it processor no if there is displacement,
and how many bytes it has and if there is sib byte.
Talking of all machine instruction size, it is not a right question "how long instruction is"
Processor actually needs to know not size but
-where is end of instruction.
-where to take operands from and how interpret them.

If you are reading a book you don't need to know what is size of the book,
you need to see punctuations to
understand logical blocks of sentences.
And know that it finished at last.
Posted on 2003-04-12 07:49:39 by The Svin
hehe The Svin!
well, i did read it all, thats why i came to conclusion by doing some binary..
at beginning i havet noticed few stuff, but its ok now!
thnx for ur explanation.
but its better to ask than just aasuming :)
Posted on 2003-04-12 09:11:30 by wizzra
I see. Thanks.

So the 1 byte opcodes are



DAA 27h
DAS 2Fh
AAA 37h
AAS 3Fh
INC 40h-47h
DEC 48h-4Fh
PUSH 50h-57h
POP 58h-5Fh
PUSHAD 60h
POPAD 61h
CWDE 98h
CDQ 99h
PUSHFD 9Ch
POPFD 9Dh
SAHF 9Eh
LAHF 9Fh
HLT F4h
CLC F8h
STC F9h
CLI FAh
STI FBh
CLD FCh
STD FDh


If there is more 1 byte opcodes please tell me
Posted on 2003-04-12 10:34:28 by roticv