B8298A4100 mov eax,418A29h
Where is eax in that?
mov B8
418A29h = 298A41?
00 = eax?
50 push eax
push = 5, eax = 0?
push ebx = 51?
B8h = mov eax,immed
B9h = mov ecx,immed
BAh = mov edx,immed
BBh = mov ebx,immed
BCh = mov esp,immed
BDh = mov ebp,immed
BEh = mov esi,immed
BFh = mov edi,immed
the low 3 bits determine the register
50h = push eax
51h = push ecx
52h = push edx
53h = push ebx
54h = push esp
55h = push ebp
56h = push esi
57h = push edi
ah doh nice 1 ty :red
instruction encoding is explained in Intel's Developers (http://www.intel.com/products/processor/manuals/) manuals Volume 2A (Chapter 2) and 2B (Appendix B)
BTW: for some instruction, like MOV, there are special (smaller) encodings when using EAX/AX/AL
looks like whoever decided that was dislexic....
B8h = mov eax,immed
B9h = mov ecx,immed
BAh = mov edx,immed
BBh = mov ebx,immed
:lol
ty for the link qWord....
BTW another quick question while I think of it.... is ml.exe written in ASM or C?
Quotelooks like whoever decided that was dislexic
eax, ebx, ecx, edx, etc - those are just names
nothing to do with the inside of the processor
Have a look the svin book about making an assembler. It explain the detail about this.
As far as ml.exe is concerned I think the move to C++ happened starting at version 8. Earlier versions were written in assembly. there are other assemblers that are not written in assembly, also. FASM is written in assembly. I like this question because I always thought it was shocking to do this as it can probably be sais that the reason that is done is because the programmers are not profricient in assembly. Then if that is true, how can they create an assembler that will work correctly and efficiently. This train of thought is born out by the known fact that ml.exe, version 8 is a piece of crap. Fails the bloat test, also, and is probably good if you like spaghetti.
Paul
Quote from: PBrennick on February 23, 2010, 08:34:47 AM
ml.exe, version 8 is a piece of crap. Fails the bloat test, also
Interesting, Paul. Do you mean the bloat of the generated executables or ml.exe itself? What is the size of version 8? I only have these:
ml v614 372736
ml v615 385072
ml v9 358384
Jwasm 313344 (19.01.2010)
v9 looks pretty neat. Either they went back to assembler, or the C compiler has become very good at optimising for size...
Version 8.0 was a pig with problems, it worked OK but had poor error checking. It looked like a rewrite that had not been fully tested which is fact probably the case. Versions 9.0 are a lot better and I would imagine the current 10.0 will be better again as the most recent rewrite matures. Old versions were a mix of C (not++) with MASM modules in it where the latest versions look like C++ without the yukkies but it needs to be remembered that later versions apparently support both ANSI and UNICODE so its doing OK size wise. I don't lose any sleep over assembly time but the 9.00 that am using is plenty fast enough against the old C/asm versions.
Well, jwasm is in C and it blows all ml versions sky high ! :bdg
Just checked goasm and it's self-assembled, hehe.
Quote from: Farabi on February 22, 2010, 09:20:30 AMHave a look the svin book about making an assembler. It explain the detail about this.
What book are you talking about?
Quote from: Sergiu FUNIERU on February 23, 2010, 04:29:57 PM
Quote from: Farabi on February 22, 2010, 09:20:30 AMHave a look the svin book about making an assembler. It explain the detail about this.
What book are you talking about?
I forget about the title, but dave gave me the link days ago. Search on the asmcommunity board and search the member who had a nick The Svin.
So for short, on every Opcode there are bit field.
For example mov eax,eax the Opcode is 88C0
The bitfield:
Command-R/M-D-S-r2r2r2-r1r1r1
Command=The Command to the processor
R/M= Is the first register are Memory
D=Direction Bit
S= I forget
88C0=1000100011000000
The Bit Filed would be 1000100-0-1-1-000-000
Im not really remember it. But more or less is like that.
heh I cant find the book, I have kinda got the above 8BC0, 8BC1 mov eax, ecx etc, will keep working on it :bg
the intel and amd programmers reference manuals are the best place to get this info
I forget the svin book title, and I did read it about 5 years ago.