explaning registers movements easy way ( thanks kulhas )

mov eax , 1 means eax = 1

mov eax , '1' means eax = 31h ( 31h is '1' )

mov eax , 12 means eax = 12

mov eax , '1234' means eax = 34333231h ( 34333231h is '4321')

capix :)

another example

section data

zuzu:
db 0
db 0
db 0
db 0,0

section code

mov eax,zuzu means that eax = to the adress of zuzu
eax points to zuzu label

mov byte ,1 means we place in eax first element number 1
eax = 1000

mob byte ,2 means we place in second element number 2
eax = 1200

we can not do

cmp eax,1200

becouse eax its only the pointer to the adress of zuzu label . eax = adress of zuzu in memory

we can compare each element !

cmp ,1
cmp ,2
cmp ,0
cmp ,0

another thing

mov eax,"1234" means eax = "4321" = 34333231h

but if we do after this line

mov eax,"1" eax = "1" = 31h

mov eax, "1234"
mov eax,"1"

its the same of doing only

mov eax ,"1"

just a litle program to test this

%include "\lab\vasm\inc\nagoa.inc"

..start:

mov eax,"1234"
cmp eax,34333231h ; eax ? = "4321"

jne not_equal
call MessageBoxA ,NULL," equal !","teste",MB_OK
jmp out_
not_equal:
call MessageBoxA ,NULL," not equal !","teste",MB_OK

out_:
call ExitProcess,0

another test
%include "\lab\vasm\inc\nagoa.inc"

..start:

section data

zuzu:
db 0
db 0
db 0
db 0,0

section code

xor eax,eax

mov eax,zuzu ; means that eax = to the adress of zuzu
; eax points to zuzu label

mov byte ,1 ; means we place in eax first element number 1
; eax = 1000

mov byte ,2 ; means we place in second element number 2
; eax = 1200

cmp dword ,0
jne not_equal
call MessageBoxA , NULL,"it is equal","info",MB_OK
jmp out_

not_equal:
call MessageBoxA ,NULL,"not equal..","info",MB_OK

out_:
call ExitProcess,0

well and after this just a final one :)

%include "\lab\vasm\inc\nagoa.inc"

..start:

section data

zuzu:
dd 0 ; size dword
db 0 ; size byte
db 0 ; size byte
db 0,0 ; size byte

section code

mov byte ,1 ; place in first element number 1
mov byte ,2 ; second element of zuzu number 2
mov byte ,3 ; thirth element of zuzu number 3

cmp byte ,2
jne not_equal
call MessageBoxA , NULL,"it is equal","info",MB_OK
jmp out_

not_equal:
call MessageBoxA ,NULL,"not equal..","info",MB_OK

out_:
call ExitProcess,0

nasm win32 group and examples here
http://groups.yahoo.com/group/win32-nasm-users/
Posted on 2004-01-27 09:01:35 by Nguga

mov eax,zuzu means that eax = to the adress of zuzu
eax points to zuzu label

Not with stupid masm syntax, where "mov eax, zuzu" equals "mov eax, "
Posted on 2004-01-27 10:50:12 by f0dder
That's Intel Syntax, MASM simply follows it, as does TASM.
I cannot deny Intel being stupid though ;)
Posted on 2004-01-27 11:11:10 by Henk-Jan
Such syntax can be debated both ways.

When you initialize the value of a label (or modify its value later) one could say that label=value, much like we learned to assign values to variables in algebra. On that basis, it can be considered quite logical if the variable y=2 to interpret

mov eax,y

as meaning move the value 2 of the variable into eax.

Some later assemblers were built to interpret the variable's name as its location in memory (some of them probably doing it only to be different from the original MASM) even though specific instructions are available to perform that exact duty and are thus redundant in such assemblers (i.e. mov eax,offset y and lea eax,y).

Raymond
Posted on 2004-01-27 12:44:43 by Raymond
Yeah he must be a C programmer. That NASM is a bunch of crap! Reversing the order? What's that about? MASM is pure nuemonic representation of machine code as it should be thank God. Sure one or two surprizes like:

repnz
movsd

it's:

rep movsd

Hey I can work with that, but please leave the bytes in their respective order. That why we understand what's happening in the machine. LIFO memory is reversed when in memory not the registers. My God what confusion. You can have it f0dder, it's about your speed.
Posted on 2004-01-27 13:13:28 by mrgone
Just what are you talking about, mrgone? masm,fasm,tasm,nasm (etc) use the same operand order: "dest, source". Quite the same as standard C library routines and assignment rules, btw.

What I don't like is the lack of constistency in masm: a variable access is a memory access, dereferencing an offset. When doing this with registers or fullblown SIB, you have to add brackets.

*forcing* brackets for variables makes the code cleaner and more consistant, and leaves the assembler with the choice of interpreting a variable without brackets as it's address - which saves me from typing "offset".

As for

MASM is pure nuemonic representation of machine code as it should be thank God.

- *cough*. As if fasm/masm/tasm/nasm (heck, even atrocious gnu as) weren't. Besides, masm is probly the least "pure" assembler, with all the high-level support it has (as if this was a bad thing).
Posted on 2004-01-27 16:37:47 by f0dder
There seems to be a bit of folklore occurring here with the syntax of different assembler. NASM for example uses square brackets for addressing as part of its design where MASM being the older and far more widespread industrial standard stil uses a derivation of the much earlier Intel standard syntax.

When you have a "LOCAL var :DWORD" in MASM, you use the NAME as the address as MASM has always done it and don't try and copy less successful assemblers that do it a diferent way.

Roughly, when in Rome, do as the Romans do so if you write GAS, write it the way it should be written, if you write NASM, do it according to its syntax rules and when you write in MASM, use the syntax correctly and don't try and copy bad habits from other assemblers.

There is no intrinsic right or wrong in the notation used by different assembler, just syntax errors by those who assume that one form should be used by others. Fortunately not everyone who wrote assembler a long time ago wrote in the style of TASM virus writers. :tongue:

Regards,
http://www.asmcommunity.net/board/cryptmail.php?tauntspiders=in.your.face@nomail.for.you&id=2f46ed9f24413347f14439b64bdc03fd
Posted on 2004-01-27 18:08:29 by hutch--
*forcing* brackets for variables makes the code cleaner and more consistant

Any programmer can write code that computers can understand. Good programmers write code that humans can understand.
Posted on 2004-01-27 18:52:07 by Henk-Jan
I have always spent more time thinking than typing - no matter the language. Maybe I am just developmentally disabled? :notsure:
Posted on 2004-01-27 19:02:42 by bitRAKE
this NASM garbage:

mov eax , '1234' means eax = 34333231h ( 34333231h is '4321')

You know f0dder you seem to be very well educated in fuctions calls I guess do to you vast C++ experience but I never here anything substitive come out of you when it comes to real low level. Oh you claim you do but everytime something goes over your head you bash it as a "cheap hack". I have been able to do more than I ever thought possible with MASM and once again I am a hardware engineer so I am more concerned with bits and bytes.
Posted on 2004-01-27 20:14:30 by mrgone
just to say :)

NASM use 100% intel syntax

Anyway you can read the nasm documentation:

http://nasm.sourceforge.net/doc/html/nasmdoc0.html

Intel syntax:
mov eax,
or
lea eax,

and
call function

is different of:
call

and NASM uses it so. All this is Intel.

NASM uses it.
Posted on 2004-01-27 20:30:36 by Nguga
Nguga, we already covered that in another thread. NASM does NOT use Intel Syntax. Use google please. Stop saying the same wrong stuff after it has been pointed out to be wrong. It makes you look stupid.
Posted on 2004-01-28 03:52:02 by Henk-Jan

this NASM garbage:

mov eax , '1234' means eax = 34333231h ( 34333231h is '4321')

I like that feature of nasm pretty much... When you see people move "text" into registers this way, it's usually to construct or check for a string. It's pretty silly having to "cmp ax, 'ZM'" or "mov , 'LLD.'" (and '23LE' and 'NREK'). Matter of taste anyway.

Oh you claim you do but everytime something goes over your head you bash it as a "cheap hack".

No, not when something goes over my head, but when something obviously is a hack. Don't assume I can't do lowlevel code just because I dislike crap code.
Posted on 2004-01-28 05:00:57 by f0dder
googling...

-----------------------------------------------------------------------------------------
at this site:

http://linuxassembly.org/resources.html

NASM x86 assembler with Intel syntax

-------------------------------------------------------------------------------------

http://www.tldp.org/

informs you :

NASM is Intel-style syntax

-------------------------------------------------------------------------------------------

http://home.ptd.net/~tms2/hello.html

How do I write "Hello, world" in FreeBSD assembler?
Thomas M. Sommers

NASM If you prefer Intel syntax in your assembler, try NASM. It is in the FreeBSD ports system.

-------------------------------------------------------------------------------------------------

http://www.bumba.net/~hmaon/a2i/

Att2Intl will convert gcc's AT&T syntax assembly output (.s) into Intel syntax (.asm), intended for compilation with NASM or Tasm

------------------------------------------------------------------------------------------------------

well .... they are all wrong ??

The University of Illinois at Urbana-Champaign
Department of Electrical and Computer Engineering
Computer Engineering II
Spring 2004

http://courses.ece.uiuc.edu/ece291/lecture/index.html

http://courses.ece.uiuc.edu/ece291/

http://courses.ece.uiuc.edu/ece291/archive/mp/f99/mp5/dev_env.html

NASM is the Netwide Assembler, a free, portable assembler for the Intel 80x86 microprocessor series, which uses the traditional Intel instruction mnemonics and syntax

--------------------------------------------------------------------------------------------------

:) but any way i?m fucking for syntax i just like logic .
Posted on 2004-01-28 08:32:07 by Nguga
Originally posted by Nguga

NASM is the Netwide Assembler, a free, portable assembler for the Intel 80x86 microprocessor series, which uses the traditional Intel instruction mnemonics and syntax

Ah yes, I found it on the internet. It *must* be correct :-).

To a lot of people, "Intel Syntax" may only mean that the assembler uses the same mnemonics and operand order as the original Intel ASM86 assembler. To those who've studied formal language design, however, a claim that some assembler follows "Intel Syntax" suggests that the assembler will process (without error) any source file that ASM86 could process (and, technically, no other source files). Today, there are no such assemblers in existence. MASM and TASM come close (though they are greatly extended beyond the original "Intel Syntax"). As Intel no longer provides an assembler or a definition for x86 assembly language, the term "Intel Syntax" no longer has any meaning in a technical sense. So it no longer makes any sense to use this term. As MASM is the defacto standard for x86 assembly language (and it is an actual extension of the original "Intel Syntax"), one could claim that "MASM Syntax" is synonymous with "Intel Syntax" in modern systems. However, to make claims about products like NASM, FASM, Gas (with the ".intel_syntax" directive), etc., being "Intel Syntax" assemblers is ludicrous. That would suggest that they all accept the same source files and they do not.

One might argue that "Intel Syntax" simply means that we use the same mnemonics and operand ordering. But why was the line drawn there? What about data declarations? What about segments? What about macros? What about equates? What about type checking (which was *definitely* a *big* component of the original "Intel Syntax")? And what about those brackets? If you're going to ignore all these other elements of "Intel Syntax", what makes the mnemonics and operand ordering so sacrosanct?

If you get sloppy with your definition of what the term "syntax" means, you wind up with people like Rene Tournois claiming that "RosAsm" is an "Intel Syntax" assembler! Completely ludicrous!

As "Intel Syntax" really no longer has any meaning, I think that the x86 programming community needs to move beyond this point and use terms like "MASM syntax" or "NASM syntax". Such descriptions would be far more precise. As best I can tell, the insistence on the term "Intel Syntax", as applied to many assemblers, is just a smoke screen to cover up failings in the design of the assembler under discussion.
Cheers,
Randy Hyde
Posted on 2004-01-28 09:54:09 by rhyde
Thank you, randall.hyde. You managed to explain it better than I have so far.

I don't fully agree on "Intel Syntax" not having any meaning however. Intel still publishes articles and sourcecode using this syntax, and MASM/TASM can still assemble this code with little or no changes (as do various inline assemblers such as the VC++ one, and I believe also Borland C++ Builder). I used to write code that assembled in both MASM and TASM back in the old days anyway.

That was my point anyway, Intel Syntax is a common subset of a group of (inline-) assemblers, and code written in this syntax can be used with little or no changes by these assemblers, and the syntax is well understood by a large group of programmers. So it still has meaning to me. And since assemblers such as NASM have a slightly different syntax, this can be confusing in communication and use, and code will have to be modified in order to work with these assemblers.
Posted on 2004-01-28 10:18:14 by Henk-Jan
I pretty much agree with Randy's comments here, its been a very long time since anyone used the Intel assembler while MASM has maintained more or less the same syntax for many years.

When you refer to NASM syntax, you know what it means as NASM uses square brackets around addresses which is simply different to the standard set by MASM.

There is no reason why anyone cannot write an assembler that uses different names for mnemonics, a different operand order and invent its own keywords but if you want code to be understandable to something like about 95% of all assembler programmers in x86, you will continue to use something similar to MASM and TASM with its data size specifiers, the distinction between OFFSET and local variables and the usual set of operators that it as mainained for so many years.

I generally agree with Randy's view about "no red tape" style assembler using this idea as a smoke screen for what they cannot do properly. Rather than hide behind nonsense like this, I do see the point of specialised tools selling their virtues, not their vices and if a lower level style of assembler allows the user to do specialised things that cannot be done in others, its an advantage.

Regards,
http://www.asmcommunity.net/board/cryptmail.php?tauntspiders=in.your.face@nomail.for.you&id=2f46ed9f24413347f14439b64bdc03fd
Posted on 2004-01-28 17:10:54 by hutch--
if you want code to be understandable to something like about 95% of all assembler programmers in x86, you will continue to use something similar to MASM and TASM with its data size specifiers

Speaking of which... oddly enough some Intel docs adopted 'word' for 32 bit entities (as theoretically they should, on a 32 bit CPU, since officially a word is defined to be the largest addressible unit of the CPU, where a byte is the smallest addressible unit of the CPU), while MASM and many other assemblers maintained the old definition of 'word' (16 bit) for backward-compatibility. So sometimes it still gets confusing.
Posted on 2004-01-28 17:27:34 by Henk-Jan