Oh, MASM does support some far jumps, it just doesn't let you specify the segment as an immediate constant. You're probably only going to have a few of those in your program anyway. I can't stand using NASM, as it can't figure out anything on its own. This isn't surprising considering it is made out of evil by commie nerds who are probably autistic. With MASM, changing an equate from 127 to 128 or vice versa does not imply that you have to go through the whole program and change all the instructions that reference it.
Posted on 2005-06-27 12:28:02 by Sephiroth3

With MASM, changing an equate from 127 to 128 or vice versa does not imply that you have to go through the whole program and change all the instructions that reference it.

Hrm, when do you have to do that with nasm?

I know there was the short/near thing in previous versions, but that was fixed later on...
Posted on 2005-06-27 14:49:18 by f0dder

Oh, MASM does support some far jumps, it just doesn't let you specify the segment as an immediate constant. You're probably only going to have a few of those in your program anyway. I can't stand using NASM, as it can't figure out anything on its own. This isn't surprising considering it is made out of evil by commie nerds who are probably autistic. With MASM, changing an equate from 127 to 128 or vice versa does not imply that you have to go through the whole program and change all the instructions that reference it.


NASM is more closely based on Intel syntax than MASM is. The whole point is not to assume anything, that is the job of a compiler.
Posted on 2005-06-27 22:09:57 by SpooK
Well, I guess the version I have may be a bit old, but surely "not assuming anything" is bad excuse for using the longest possible encoding for an instruction when there's a shorter one that does the exact same thing? Let's say I have a structure named RECORD and it is 124 bytes in size.

So, what if ECX points to one of these structures and now I want to advance to the one that follows it? I write "add ecx, byte RECORD_size". I can't just write "add ecx, RECORD_size" since that of course is a DWORD or "oh, then the output wouldn't be predictable". And I end up doing that a whole lot of times in my program. Ok, next year I decide to add a new field to my structure, making it 128 bytes. And then I have to do find all the places where I pushed, added, subtracted, multiplied or whatnot RECORD_size and change them to use their DWORD form instead. The funny thing is that it can encode addresses jolly fine, so "lea eax," of course becomes what I want it to no matter what number RECORD_size is.

Okay, sometimes when you're writing self-modifying code, you may want to use the longer form of the instruction. But why does it have to be the default?
Posted on 2005-06-28 10:29:13 by Sephiroth3
Ah, that's what you meant :)

Agreed, havin'g to do the byte prefix is sillly - the assembler should provide the most efficient encoding, but let you specify overrides for when you need it...
Posted on 2005-06-28 13:53:08 by f0dder

Ah, that's what you meant :)

Agreed, havin'g to do the byte prefix is sillly - the assembler should provide the most efficient encoding, but let you specify overrides for when you need it...


Those kind of assumptions are for compilers to make, not assemblers. What may seem efficient may, in actuality, not be the best option. Cleaning up the inconsistancies of a bad programmer/programmer who refuses to RTFM is never an excuse.
Posted on 2005-06-28 20:42:00 by SpooK

Those kind of assumptions are for compilers to make, not assemblers. What may seem efficient may, in actuality, not be the best option. Cleaning up the inconsistancies of a bad programmer/programmer who refuses to RTFM is never an excuse.

Shortest instruction is usually what you want... if you *need* longer encoding, you can always specify an override. Not doing jump/data size optimization and claiming "it's not true assembly to do so" is just a lame excuse for people who can't code an efficient multi-pass assembler :p
Posted on 2005-06-29 04:19:32 by f0dder
Like I said, optimization is for compilers. There are even switches available in NASM, including optimization ones (for whatever reason), to aleviate these types of assumption problems.
Posted on 2005-06-30 01:26:28 by SpooK
In the case of size optimizations, I beg to differ. When there are both short and long encodings for an opcode, the mnemonics don't convey whether to use short or long encoding. If you don't think an assembler should make any assumptions, unique short/long mnemonics should be chosen for opcodes that have multiple encodings - or size overrides should be applied everywhere.

Which is somewhat silly, in my opinion. And a lot of other people's opinion too, it seems - otherwise fasm and nasm probably wouldn't do multiple passes to do size optimizations :)

And it's still possible to *add* specifiers so you can explicitly state whether you want a short or long encoding, for cases where it matters.

Oh well.
Posted on 2005-06-30 08:12:25 by f0dder
You're wrong, not for technical or empirical reasons... you are simply wrong for the principle of the matter :)
Posted on 2005-06-30 17:46:26 by SpooK
Now you're just being plain silly... oh well.
Posted on 2005-06-30 17:51:15 by f0dder

Like I said, optimization is for compilers. There are even switches available in NASM, including optimization ones (for whatever reason), to aleviate these types of assumption problems.

What about manteinability? Suppose you do want the shortest possible jumps. Whenever add something to your code, you'd have to go through all your jmp instructions and make sure they're the correct size. That's not the job of the programmer... and if it isn't of the assembler either, then who's is it? ;)
Posted on 2005-06-30 18:49:07 by QvasiModo
-O<digit>  optimize branch offsets (-O0 disables, default)


By the way, if you dont know what I mean... http://nasm.sourceforge.net/doc/html/nasmdoc3.html#section-3.7



Only a apointment (or is writed remark?) ;).. or an annotation, I always have looked that remarks against nasm fall in that say that.. optimization about branches.. etc, optimization about push dword 33, and more etc.



What I know is that you dont know this assembler completely (also I dont know it completely...)... and that is aceptable because you dont use it.






Tought valid argumentations that I can acept about this assembler is the assembly time required when there is a lot of structures defined (like the nagoa.inc and others include files). Perhaps some about floating point (formats acepted.. parsed.. dont know) I dont have knowledge in that regard.

I guess that little section in the documentation clear completely the argumentation of f0dder, QvasiModo , and many others that before they have "showed" that there no exist this thing in the assembler and that is not the work of the human using assembly language.... tought, I dont understand completely what Sephiroth3 try to show... perhaps an example can be a best explanation....




By the way, the otimizer used, for example, yasm claim to have a best optimization than nasm...


But why does it have to be the default?

Because is designed like that. If you will whant optimization always, you can easely modify the source code for that... (instead of making a .bat file for example...
Posted on 2005-06-30 19:45:00 by rea
Refering to add... then http://nasm.sourceforge.net/doc/html/nasmdocb.html#section-B.4.3

The problem that If I understand correctly Sephiroth3 remark is something like the following....

The STRUCTURE_size is a definition, like %define n 23...



%include "..\..\include\general.mac"
%include "..\..\include\w.inc"

%define va 124
%define vb 250
%define vb2 256
%define vw 0xFFff
%define vd 0xffFFffFF

segment .code class = code use32
%define LINKERUSED GOLINK
MakeEntry
add eax, byte 123
add eax, byte va
add eax, vb
add eax, byte vb2
add eax, vw
add eax, vd
push dword 33
push byte 33
ret


The v prefix mean variable... b = byte, w = word, d= double
Look carefull, specially to vb2 that in fact can`t be represented in less than a byte.

When you assemble that there is a warning...


opti.asm:16: warning: signed byte value exceeds bounds


And the whole file is assembled like:


00401000 >/$  83C0 7B      add eax, 7B
00401003  |.  83C0 7C      add eax, 7C
00401006  |.  05 FA000000  add eax, 0FA
0040100B  |.  83C0 00      add eax, 0
0040100E  |.  05 FFFF0000  add eax, 0FFFF
00401013  |.  05 FFFFFFFF  add eax, -1
00401018  |.  68 21000000  push 21
0040101D  |.  6A 21        push 21
0040101F  \.  C3            retn


You see, that isntruction, is cuted, because the value exceed a byte... and was assembled like if the remaining is a byte.

You have the way for correct that suguested before, but instead of searching, you can use the warnings gived by the assembler.










But there is how you use the assembler, you know now the guidelines "no assumptions", no optimizations and assumption will be that the value that you have writed that will be a byte, and exceed a byte, will be an assumtion if the assembler try to override the size gived by the programmer by the size that itself can calculate.




If you decide to use the assembler to do exactly what you whant, then dont use optimization, do what exactly you say to do mean that you know the impact of the things like Sephiroth3 has pointed but say that dosent like, is because the assembler in this mode dosent assume nothing more than what you write down (hope you now see clear the concept).

If you decide that the assembler can help you, because you know what to do but not exactly (like Sephiroth3 say) what you will do in a year or a month or a day... then use the optimizer...

Hope you understand now, what is the meaning to have an assembler that dosen't assume nothing and do what is exactly writed, only do what is writed down, but remember that this assembler can help you.

By the way, you consider optimization in some cases mov eax, 0 to be xor eax, eax. In the case of nasm, choose between the most large and short encoding is an optimization. In the mode that the assembler dosent assume nothing, is the work of the human make the anotation for isntruct the assembler to use the shortest instruction... you see, no assumtions, no optimizations....



By the way, I have missed that if you choise to use the optimizer you dont need to use the size overrides... for say to the assembler exactly what to do...


%include "..\..\include\general.mac"
%include "..\..\include\w.inc"

%define va 124
%define vb 250
%define vb2 256
%define vw 0xFFff
%define vd 0xffFFffFF

segment .code class = code use32
%define LINKERUSED GOLINK
MakeEntry
add eax, 123
add eax, va
add eax, vb
add eax, vb2
add eax, vw
add eax, vd
push dword 33
push byte 33
ret


Assembled with nasmw -win32 -O999 opti.asm like:

00401000 >/$  83C0 7B      add eax, 7B
00401003  |.  83C0 7C      add eax, 7C
00401006  |.  05 FA000000  add eax, 0FA
0040100B  |.  05 00010000  add eax, 100
00401010  |.  05 FFFF0000  add eax, 0FFFF
00401015  |.  83C0 FF      add eax, -1
00401018  |.  6A 21        push 21
0040101A  |.  6A 21        push 21
0040101C  \.  C3            retn
Posted on 2005-06-30 21:51:14 by rea
Hehe, now I take over a comment of Spook ;)

NASM is more closely based on Intel syntax than MASM is. The whole point is not to assume anything, that is the job of a compiler.


I like to think that is only related to Intel sintaxis, but yes, it dosen't is Intel sintaxis :).

Time a go, in a discusion, a guy (let me search it...), trying to show that nasm Sintaxis is not Intel Sintaxis, has suguested a very nice name for nasm sintaxis, I know that not much people will follow me, in the thing of the name for the nasm sintaxis, but I like the name.

The guy called it the nasm sintaxis is mnemonic syntaxis, and I stay a little in my place, and I say eureka (is writed like that?), yes, this guy hit in the nail, it is not Intel sintaxis, is mnemonic sintaxis :), is more direct related to mnemonics than to Intel sintaxis.

I like to think in the nasm sintaxis like mnemonic sintaxis :).

The thing, about optimization is widely explained above ;).


And the here is the link, by the way, fit exactly the lat two post, is what I need to show :). http://www.asmcommunity.net/board/index.php?topic=16939.30

tought rereading them... I guess I have coined more the concept of "mnemonic sintaxis", Henk-Jan only give me the hint :)... with this arguments...


NASM does use x86 mnemonics, but that's rather obvious


And

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


He said something else, I said something else is mnemonic sintaxis :)...
Posted on 2005-06-30 22:11:53 by rea


NASM is more closely based on Intel syntax than MASM is. The whole point is not to assume anything, that is the job of a compiler.


????

Most certainly not. MASM is a superset of the Intel syntax (Intel only maintain an "official" syntax up through their ASM386 product, after which they just used MASM for everything).

Take a look at the ASM86 manual (from Intel) sometime. You'll see ASSUMEs, BYTE PTRs, type checking, no brackets around memory references, all the stuff you find in MASM and don't find in NASM.

Today, of course, Intel's comment is "we don't specify an official syntax." (I believe Donkey got that phrase out of them, but I may be wrong). This make sense, as Intel no longer produces an assembler. Nevertheless, the syntax they specify in their data sheets more closely resembles MASM than anything else.

Of course, you'll find code samples from people at Intel written in a half-dozen different assemblers. None of that suggests that this is an "official" Intel syntax, it only means that the person who wrote the particular code used the given assembler. Some examples from Intel do indeed use NASM, largely because of the portability of the product, not because they particularly promote the NASM syntax.
Cheers,
Randy Hyde
Posted on 2005-07-27 20:06:45 by rhyde
No one will allow me to live in ignorant bliss anymore :cry:
Posted on 2005-07-28 16:18:23 by SpooK

No one will allow me to live in ignorant bliss anymore :cry:


Well, this "NASM is the official syntax" is a sore point with me, because that's the lie that Rene Tournois keeps trying to spread in ALA.
Cheers,
Randy Hyde
Posted on 2005-07-28 21:44:53 by rhyde
I really don't see any syntax as "official"... everyone has their own flavor... and that shouldn't be pushed onto others.
Posted on 2005-07-28 22:10:01 by SpooK
I think I saw a sentence along the lines of "modelled after the intel {standard,syntax,whatever}" somewhere, sometime, in the NASM documentation. Which would indicate that it's not the `official intel syntax`, but a derivate :)
Posted on 2005-07-28 22:14:09 by f0dder