And when doing direct binary output, I still prefer fasm/nasm - since there's no "ripcode" additional step.


Well I rarely need raw binary code anyway... And when I do, I can't be arsed to work with broken syntaxes such as nasm/fasm. I prefer to just use the good ole MASM or C/C++ power.
But sure, there are areas where one tool is better than another. Which is why we have multiple tools :)
Posted on 2004-01-25 06:47:48 by Henk-Jan
hehe... I don't think nasm/fasm are broken syntaxes (while I do think masm allowing memory indirection without brackets are a bad thing). Especially nasm can be annoying if you need "high-level" kind of stuff though - but I generally don't need that for assembly code (high-level code in a low-level language? Gimme the real deal, thank you :))

If I needed to inject enough code that self-relocating code is annoying and C/C++ would be nice, I'll just put it in a DLL instead... works like a charm, that's how I did it for the XCOM bugfixes.
Posted on 2004-01-25 06:54:14 by f0dder
I don't think nasm/fasm are broken syntaxes (while I do think masm allowing memory indirection without brackets are a bad thing).


Well, MASM simply follows the syntax that Intel defined. That's the point... The syntax is well-defined. I have never seen a decent definition of nasm's syntax. All I know is that it's not Intel's syntax.

but I generally don't need that for assembly code (high-level code in a low-level language? Gimme the real deal, thank you )


Well the way I see it, if I *have* to use asm anyway (as in, high-level languages don't cut it), I want to make it as comfortable, easy and fast as possible. MASM does this for me. Most of the time I just use inline asm though.
I suppose it depends on what you're doing, and how you want to do it. I spend most of my time writing the code, so to me it's important that this part is the easiest. That I might need an extra 'rip'-step, is not important, I don't do that very often anyway, most of the time I'm coding ;)
Posted on 2004-01-25 07:12:16 by Henk-Jan
I learned from here http://www.asmcommunity.net/board/index.php?topic=16755 that masm hll features that they was only macros, folowed by a parser that let you extract interesting expression, byt the way... nasm not have suchs hll constructs, but there exist macros to.. for do the work for you. Also Like I say in the other post, you eventually take a format for do things or a standar in code selections, jumps, etc,.

Also people say that nasm dont have the features that others have... here is a feature that masm dont have (they dont take care o such a simple format?, but is the way that the computer start... or take for first.. in this way, I think they ignore the priciple), maybe they have such a feature but is not public... ??.. or maybe simply they dont have.


Yes... the correct tool for a specific work.

I what to share with you some.... I read time a go books on logic, and express a thing like "the mathematic people dont care if the correctness of what they write, because is a standar follow the expressions that they use", what is refered is that there exist errors for example in geometry.... not only in the proof of theorems but un the theorems inself!!!!, also if I remember correctly Djikstra express some like that, there exist diference in how you use the words and order, but standar comes more strong that a correct expression.

That is all that I say, dunno if nasm sintaxis is the correct, but for me make sense, maybe is not a good software... maybe.. you see dont have the implementation of exitmacro (that in some way... can be easy to implement.. because there exist a anterior "bug" that at less exit the rep-blocks), but can output the raw bin format, also output other formats, the nasm sources are a "spagetti... or cant be readed", O share with you some in the past, I do a modification that whas not aproved, and the degree in C, the more high that I have in that time was the basics of pointers, not more, what I say, is if a person with that degree can read that spagetti codes, why others more skilled people say that they can not read it?.

Have a nice day or night.
Posted on 2004-01-25 09:37:33 by rea
> The syntax is well-defined. I have never seen a decent
> definition of nasm's syntax.

Can you explain what is a decent definition of a syntax?

Anyway you can read the nasm documentation:
http://nasm.sourceforge.net/doc/html/nasmdoc0.html

> All I know is that it's not Intel's syntax

I have the impression that you have never used NASM.
NASM use 100% intel syntax.

What you call intel syntax: invoke, proc, if, while, offset, addr
byte or dword ptr, assume?
Posted on 2004-01-25 11:09:46 by n u M I T_o r
Can you explain what is a decent definition of a syntax?


A formal specification of such.

I have the impression that you have never used NASM.


How is that, because I don't like it? NASM is not the holy grail of assemblers, it is quite possible for someone to use it, and not like it.

NASM use 100% intel syntax.


Wrong. I have the impression that you do not know what Intel Syntax is.

What you call intel syntax: invoke, proc, if, while, offset, addr
byte or dword ptr, assume?


What I call Intel Syntax, is the syntax that Intel uses in their documents, and the syntax that assemblers such as MASM and TASM (when not in ideal mode) understand.
proc, offset, byte/dword ptr are part of those, for example. Whether or not assume is part of it, can be argued, I guess.
The others that you mention are MASM-specific macros (although IF is partly supported by TASM aswell).

Anyway, let's take this rule of thumb: If I can copy a listing from an Intel manual, and assemble it as-is with an assembler, then it most probably supports Intel Syntax.
NASM does not, it has different rules for many things, and I find these rules ill-defined, that is, not even in the page that you linked to, is it explained afaik.
Posted on 2004-01-25 12:38:01 by Henk-Jan
FASM cannot return value from macro either
Posted on 2004-01-25 13:16:50 by comrade
I think there is explained ;)

Is simple like this:

All in your sourcefile is data, this data have a address specific in the file (In reallity in the final format), you mark a specific address with a label (append ':' or dont use ':'), for use the address you only use name, for get the content at the address you use [].

That is all that you need know for handle nasm :)

let see if you undertand how easy was:

hereAMark
mov eax,
jmp hereAMark

You already know nasm syntaxis!!!!...


Yes there are some miss in the documentation.. there are some features that not much know (little they are, but are there...)


Maybe you are thinking that is good have the byte ptr, for my not, why type more in a instruction like this?

mov byte ptr , 255 when you already know that if you put [] are referencing the content at, the modifier byte is necesary for the ambiguity, see the note1.

mov al, byte ptr also in nasm, you use: mov al,, here you see is superflows put byte ptr... because you already know the size for get (note1)... also you already know that is a ptr.... because if not... for what you will use [] that reference the content of memory? hehehehehe, I supose that masm is so good for see the error if you use a instruction like this: mov al, word ptr, here you see, if masm give you a error here... masm already know how the instruction will be assembled (mov a byte), but having options that let you be 'superflous' I think that is the correct word. Like you see, more tipying, more tyip?ng is good and have options is good, but I think only when they are good options.

note1: when you get/write or compare a memory, you have two things, the size of the address, and what address I need know the content, in nasm you only use [] for reference the content, then you already know that is what masm call ptr, the first thing to get, is what address, and this is inside the [], like this , and the second thing is the size of the operation, how many I whant get/write use/like_compare, if you give a register to the instruction for destine or source, the size modifier not have any sense!... because you cant move a dword from a 1 byte register, and if you whant to move the content of a 1 byte register to a memory, how this content will be expanded to fit in 32 bit memory?, the only case when you need a modifier for nasm size operand of memory is when there o exist a register.

cmp , byte 0
cmp byte, 0

Here you see, a option that nasm give you, you can specify the size to the constant or the memory, but this is not ambihous, because like I say before if you know the size of the operand that is a byte, you can not get a size of a word of a operand that the size is one byte, equaly that if you know the destination can be filled with a byte, then the operand need feet in this size.

note2: The only place that you will see [] other that for reference addresss, is with lea and friends, lea eax,

note3: If you take that standar of intel docs, I am glad that nasm dont suport the intel sintaxis!!!!, this is more easy to understand and to type, the only that suport nasm from the intel sintaxis is the order of operands, the name of the registers, the ways of direction sometimg.. without use the superflows modifer of size where they are not neesary and the format of [] for address, also see that [] is like a box, is more graphic representation of content of memory, the isntruction set, also I think suport some things that are only from AMD.

note3: you use masm because it give you de hability of write more fast code, because is structured programmin constructs...please dont miss what is a hll and what is structured programming!!!, if you use because give you this hability of structured programming... then see that insert in your typing and expression of solution some superflows instructions... that they are not really necesary.



At the end we make solutions, but we express with the language of our choice, I think masm is powerfull, but I dont feel confortable with, for me nasm make more sense.

Also like you say, maybe nasm is not the holy grail (I dont know what is grail... but i reuse your words), for me masm is not too, but is more confortable, simple and sintetised for me nasm.

Yes I am not saying that nasm dont have bugs... and other things, I am only saying that is more easy express a solution here, but like all, you need practice.


Have a nice day or night.
Posted on 2004-01-25 13:58:49 by rea
>> Can you explain what is a decent definition of a syntax?

> A formal specification of such.

In what formal language do you want it? First Order Logic?

I think that this is job of the cpu designers, they decide
the instructions and mnemonics to use, no the assemblers
designers.

Any way, what is the formal specification of the MASM syntax?

> NASM is not the holy grail of assemblers, it is quite possible
> for someone to use it, and not like it.

Yes, but neither MASM.

I'm not saying what you must use. I only ask how can
you speak about something that you neither use nor know?
by pure imagination?

> I have the impression that you do not know what Intel
> Syntax is

No, I wrote a ix86 dissasembler without read the intel manuals!
Great miracle!

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.

> proc, offset, byte/dword ptr

I believed that those MASM/TASM reserved words were
not CPU instructions. What does the proc instruction?
what is its opcode?

I believed that 'offset' was a operator, not a CPU instruction.

> If I can copy a listing from an Intel manual, and assemble it
> as-is with an assembler, then it most probably supports
> Intel Syntax.

Sorry, but there are so many listings in the Intel manual that I don't know what choice.

> NASM [...] has different rules for many things, and I find these
> rules ill-defined, that is, not even in the page that you linked to,
> is it explained afaik.

What! Give me a example.
Posted on 2004-01-25 14:10:46 by n u M I T_o r
A yess... I miss that one about the offset, like I say in the past, all in your sourcefile is data, and you mark specific locations with a label (only for not need to see where this realaddress is)

I am not profitable in what is offset, even you see that I miss that one!!!, but what I know is that is only used for get the address in the code of a label, where in nasm, you only use:

mov eax, aLabel
in masm, you use some like:
mov eax, offset aLabel


I see two posibilities here, for what the masm developers choice (yes, even this guy need to choice), this format, I think that in masm you can not use:

mov eax, aLabel

returning to a brief analisys, you like a programmer, already know that you whant move the address of the label to the register eax, is that what you express in that line (for any later porpouses that you whant....) ... if not... you where not using offset, you know that you need use offset, but for what masm can not get the address directly??, whitout saying that I whant the offset? explicitely?

because I thing in some cause, (the first cause), some others masm sintaxis make mov eax, aLabel superflous or whas a collition of sintaxis..... inside masm, and getready for more extra typying (and they insert offset)... or because simple (the second cause)... masm can not diferentiate between a definition or a symbol defined by a equate and a label!!!!!

If this is, I im impresed, because some of the things that I listen much times, is that masm parser is a lot so good, and I think it was... only when I analise now the posibilities for what masm need offset is that I see that the parser havesome faults too... masm can not diferentiate between a label and a equate?...and you need access directly the table of symbols? with the operator offset?

Or I am going to far??, and is only simply a bad sintaxis design.


The last that I say..... this is more extra typing... when you do mov eax, aLabel, in nasm you already know that you whant move the address, and the "simple assembler" like nasm, know that you whant the address of this symbol, but with masm you not only know that you whant to move the address, but explicitely say to your assembler what you whant.

Maybe you are thinking that in nasm you need too explicetely say to your assembler what to do, in fact, this is not true (only with the undefined operand read/write/manipulations), and if you whant other features, you can still read the nasm documentation.....


Have a nice day or night.
Posted on 2004-01-25 14:35:22 by rea
Intel Syntax is the name for the assembly language syntax that you can write x86 programs in, as defined by Intel.
It is MORE than just the x86 mnemonics.
MASM and TASM obey Intel Syntax (and add some extra macros, directives and such), NASM does not.
NASM does use x86 mnemonics, but that's rather obvious, even AT&T syntax uses those, and it is about as far from Intel Syntax as you can get.

In short:
mov eax, dword ptr [0] is Intel Syntax
movl (0),%eax is AT&T Syntax
mov eax, dword [0] is... something else.

That is all I have to say about it, for the rest: use google.
Posted on 2004-01-25 14:51:19 by Henk-Jan
is only mov eax, [0] (I think you not read the anterior post ;) )

Also I think that maybe I not explain well the thing about the mathematics and logics... but hey... if you can have a more clean sintaxis... even if the standar use other, but if you can get a clean sintaxis...why not use it?


I am not saying that you need use nasm, but you need take care that you can have a more clean sintaxis, and yes, like you say, that is intel sitaxis, why(replace why with we) programm for the processor... the one that you call 'something else' is more near to what a mnemonic is... like you state here, and you give a point to to AT&T sintaxis...., because you say that he uses mnemonics equal than nasm.


I think here you explain well the point, masm is Intel sitaxis, and nasm is mnemonic sintaxis.

Also the mnemonic sintaxis is more clear than Intel one, I think can be good recognogize that is a more clean sintaxis, and without ambiguities... even if you dont use....


have a nice day or night.
Posted on 2004-01-25 14:59:47 by rea