A strange problem with %include that blew me off

[tarek89]

Well the problem is so strange lemme discuss

first i had my proc saved on a file called T_linux_32.inc
i usually start my programs including this file by
%include "T_linux_32.inc"

it  worked since the day i started including but suddenly yesterday i was retesting my program it really showed me strange error that all procedures am calling are undefined!!!!??

i thought there is something with the assembler itself so i reinstalled it but same error appears
what made me really wanna explode is that, there is only one program that worked with this state while others didnt although there is no difference in calling or including the file !!

is that normal ??!

[Frank Kotler]

Well, no, that is not normal. I strongly suspect "typo".

There are a couple of characters that might throw Nasm for a loop. One is the "line continuation character", '\'. If that occurs at the end of a line, and it's in a comment, it'll make the next line a "comment", too (and thus ignored).

Another one I encountered a long time ago, if memory serves, was 1Ah. This produced (in dos) a right pointing arrow - like "->", but a single character. I was using it to indicate "subdirectory" in a directory listing. "mov dl, 1Ah", or so. Worked fine, but then I "improved" the program by adding a comment indicating what that character was (had to beat the editor into submission to produce it). Nasm took this as "end of file" and ignored everything after it - making a bunch of stuff "undefined". Foolishly, I made this change along with a lot of other changes. Drove me ape-feces! Who would have thought that a character in a comment could cause that much trouble? But that and '\' can do it!

If you can't find the problem, put more eyeballs on the job - post the code!

Best,
Frank

[tarek89]

you know what i cant stop laughing =D=D
its really cuz of "\" in a comment above it
omg how come this, isnt it a glitch ??! cant we post it for NASM developers to handle this ?? or does it really have a good function or something i didnt see =D?!!

Thank you very much frank you are really great =)

[Frank Kotler]

It is "intended behavior" for a line-continuation character. Might be kinda "glitchy intended behavior", but it's "on purpose". Broke some existing code when it was first introduced (some of Jeff Owens' code, IIRC), but we really "need" (or want) a line-continuation character, and that's how they're "supposed" to work. Think of it as a "six-legged feature".

Best,
Frank

[tarek89]

yea it really may help in some cases but it is really stubborn not to mention this description in the manual.. it drove me crazy to get to know what the hell =D

another strange problem i always face is
sometimes ( mov edx,[buff] )  if buff has only one byte which is 2 for example i need to load edx with 2 only sometimes this statement works and sometimes it loads another big value which leads to printing out strange characters and squares
doesnt mov edx,[buff] means to move content of offset buff to edx i mean the whole edx not only dl ??

[Frank Kotler]

Well, yeah! If you want just a byte, use dl. If you want to zero-extend a byte into edx, "movzx edx, byte [buff]". (to sign extend, "movsx").

The line-continuation character is documented:

http://www.nasm.us/xdoc/2.09.08/html/nasmdoc3.html#section-3.1

... probably could be made easier to find...

Best,
Frank

[tarek89]

wow i never saw this line

thank you alot for your great help sir =)

[tarek89]

although i have never knew about movzx or movsx

what happens when i mov ecx,[byte]
assuming byte has 2
using the debugger i found out it is 2 in ecx

[Frank Kotler]

Depends on what comes after your buffer...

Code: [Select]

buf db 2
; buf2 db 3, 4 5

mov reg32, [mem] loads 4 bytes. Neither Nasm nor the CPU knows how many bytes are in your buffer. If your (byte) buffer comes last in its section, it is likely padded out with zeros (else it will segfault!), which will hide the "bug", but it is still a "coding error"! Many assemblers *do* remember how big you said the variable was, but Nasm does not. This is intentional (for better or worse).

Best,
Frank

[tarek89]

ahh i got it, so performance wise does movzx or movsx takes more cycles than the original mov ?? does it really affect the program execution time?!

[Frank Kotler]

I don't know. http://www.agner.org has info on instruction timing - probably depends on which CPU.

 A possible alternative...

Code: [Select]

mov edx, [buff]
and edx, 0FFh

... might be faster(?), but would still segfault if "buff" were right at the end of "valid" memory. Why are you using edx (or other 32-bit reg) if all you want is a byte?

Best,
Frank

[tarek89]

printing in linux 32 bit  uses extended registers EAX,EBX,ECX,EDX

[tarek89]

mov instruction takes only 1 cycle
while and ranges from 1-3
and movsx or movzx takes 3 cycles

that wont affect that much on recent processors i guess