nasm-users — Discussion and help for Nasm users.

Re: [Nasm-users] How to call MessageBoxA from Nasm program?

[Frank K. <fbk...@zy...>]

oh...@co... wrote:
> Hi,
> 
> I'm trying to add a call to MessageBoxA in a Nasm app.  I know how to setup the parameters for the call, but I can't get Nasm to assemble successfully.
> 
> I have added an "extern MessageBoxA" and "import MessageBoxA user32.dll" (this is on Windows), but when I do that, I get an error from parser saying that an instruction is expected.
> 
> If I comment out the "import" line, I get a linker error.
> 
> Am I not suppose to use both the "extern" and "import" lines, before the .Code line?

Mmmm, yes, but only in "-f obj" output format (which defaults to 16-bit 
and requires some "cruft" to tell Nasm we want 32-bit). Supposedly, in 
"-f win32" format, we "don't need" it. I think the reason we "don't 
need" it is that we are expected to link with an "import library" on the 
linker command line. I am told that we can create our own import library 
by assembling "extern MessageBoxA" and "import MessageBoxA user32.dll" 
(with other extern/imports we need, presumably) as "-f obj" and linking 
the produced .obj with the .obj containing your code (assembled as "-f 
win32") - despite the different linkable object formats, this is 
supposed to work. I was told this after I'd quit running Windows, so 
never had a chance to try it. I think the more "usual" way would be to 
link against an import library supplied with your linker(?). This raises 
the obvious question: which linker are you using? And what, if anything, 
came with it? I don't know much about Windows linkers - I used Alink, 
mostly, for the few Windows programs I tried. I think Golink and Polink 
are more common these days.

You might want to download the "nasmx" package:

http://www.asmcommunity.net/projects/nasmx/

Recent versions have been in .exe format, so I can't even look at it to 
see what's there. Uses Golink, it says that on the web page... If it 
doesn't include a "win32.lib" or such, the examples may give you an idea 
how to function without it.

If all else fails...

http://home.comcast.net/~fbkotler/win32nasmbase.zip

...as I recall, that includes a library that worked with "-f win32", 
although it is extremely old and obsolete...

This question about "import" comes up fairly often, and I don't really 
have a "good" answer to it, besides "it's for -f obj only" and we "don't 
need" it for -f win32... Anyone got a clearer idea on this?

Best,
Frank

[Nasm-users] How to call MessageBoxA from Nasm program?

[<oh...@co...>]

Hi,

I'm trying to add a call to MessageBoxA in a Nasm app.  I know how to setup the parameters for the call, but I can't get Nasm to assemble successfully.

I have added an "extern MessageBoxA" and "import MessageBoxA user32.dll" (this is on Windows), but when I do that, I get an error from parser saying that an instruction is expected.

If I comment out the "import" line, I get a linker error.

Am I not suppose to use both the "extern" and "import" lines, before the .Code line?

Thanks,
Jim

Re: [Nasm-users] How to call Win32 printf from Nasm?

[Frank K. <fbk...@zy...>]

oh...@co... wrote:
> Hi,
> 
> Can anyone tell me how to call Win32 printf from a Nasm program?
> 
> I've been trying:
> 
> mov eax, msg
> push eax
> call _printf
> .
> .
> .
> msg: db 'this is a test', 10, 0
> 
> and that seems to work, but the stack seems to be messed up after that, so i'm wondering if there needs to be a "pop eax" after the call?

Probably. As you know, the usual API is stdcall - callee cleans up 
stack. But printf, or anything that takes a variable number of 
parameters really *can't* work that way... So you'll have to do it - 
"pop eax", or "add esp, 4", or "lea esp, [esp + 4]"... even in Windows.

> Also, what other parameters can be used, e.g., can I provide printf with a format string, and if so, how?

Well, here's an example for Linux...

; nasm -f elf hwso.asm
; ld -I/lib/ld-linux.so.2 -lc -s -o hwso hwso.o

global _start
extern printf

section .text
_start:

     fld qword [anumber]
     sub esp, 8
     fstp qword [esp]
     push msg
     push fmt
     call printf
     add esp, 16

     mov eax, 1
     xor ebx, ebx
     int 80h

;section .data
     fmt db "%s%f", 10, 0
     msg db "The answer is: ", 0
     anumber dq 42.0

For Windows, you'll want an underscore on "_printf". Nasm will do that 
for ya - "nasm -f win32 --PREFIX _ myprog.asm" or so (puts an underscore 
on all "extern" or "global" variables). The "int 80h" won't work, of 
course - ExitProcess instead... Note that printf expects double 
precision floats for "%f"! (*not* a "Linux thing", AFAIK). (important to 
know, since printing floats is the only excuse for printf :) I don't 
know what the command line to the linker needs to be - "whatever you're 
using" should be okay.

New Nasm feature: you can use "\n" and the like, if you enclose the 
string in "back apostrophes" '`' instead of ' or ". (under the ~ on my 
keyboard)

format_string db `hello\n`, 0

Thanks for the question, Jim! First message I've been able to approve in 
ages! :)

Best,
Frank

[Nasm-users] How to call Win32 printf from Nasm?

[<oh...@co...>]

Hi,

Can anyone tell me how to call Win32 printf from a Nasm program?

I've been trying:

mov eax, msg
push eax
call _printf
.
.
.
msg: db 'this is a test', 10, 0

and that seems to work, but the stack seems to be messed up after that, so i'm wondering if there needs to be a "pop eax" after the call?

Also, what other parameters can be used, e.g., can I provide printf with a format string, and if so, how?

Thanks,
Jim

Re: [Nasm-users] Please help with assembler program

[Frank K. <fbk...@zy...>]

harlequin88 wrote:
> I need help... ia have to do program on I8080 platform, but i have no
> approach about it. Please if you help me i will be grateful.
> 
> my problem is:
> 
> Count up number of words, which count (addition) ASCII codes number (letter)
> is bigger (greather) than 200. Write up result (achievement) in decimal
> code.
> 
> 
> an example: Old house is big.  - word house has bigger count of ASCII code
> than 200 so result will be 1.

I've never done anything with 8080 - don't think Nasm will emit code for 
it - so we may not be able to help you much...

The overall approach would be something like...

get the address of your string into a register
zero a register to use as an "ascii counter"
zero a register to use as a "words over 200" counter

top:
get a character from the string into a register (8-bit)
bump the string pointer register
check if it's a zero (end of string)
   yes - is the "ascii counter" over 200?
     yes - bump the "words counter"
     either - go to exit
   no...
check if it's a space (end of word)
   yes - is the "ascii counter" over 200?
     yes - bump the "words counter"
     zero the ascii counter
     goto top
   no...
     add this character value to the "ascii counter"
     goto top
exit:
   ... however you do that on whatever OS your 8080 is running

You may need an extra step in there to "print the result". I guess 
that's the "decimal code" you mention? You probably do that by dividing 
repeatedly by ten... the "remainders" are the digits you want to print - 
add '0' to each one to "convert" it from a digit to an ascii character. 
That's how you'd do it on 8086 - I assume 8080 has similar 
instructions(???).

If you post what you've got so far, we *might* be able to help you debug 
it, even if it isn't x86/Nasm. "Code is code", I keep sayin'...

Best,
Frank

[Nasm-users] Please help with assembler program

[harlequin88 <har...@gm...>]

I need help... ia have to do program on I8080 platform, but i have no
approach about it. Please if you help me i will be grateful.

my problem is:

Count up number of words, which count (addition) ASCII codes number (letter)
is bigger (greather) than 200. Write up result (achievement) in decimal
code.


an example: Old house is big.  - word house has bigger count of ASCII code
than 200 so result will be 1.

Please, THANKS A LOT.
my email address is har...@gm...


-- 
View this message in context: http://www.nabble.com/Please-help-with-assembler-program-tp22681107p22681107.html
Sent from the nasm-users mailing list archive at Nabble.com.

Re: [Nasm-users] code problems--relatively new

[Frank K. <fbk...@zy...>]

Tyler Littlefield wrote:
> awesome, thanks again for the help.
> Last thing, I think, then I'll go away.

Sorry for the delay. Couldn't bear to see you leave. :)

> I've seen code that linkx with the c lib. I'd like to write my own 
> functions and run those, as they'd probably be faster, but until I learn 
> how, I'll chill with the c lib.
> What is the best way to do this--I seen one post in google, and it was 
> thurally unrelated to what I was going for--after about 3-5 searches and 
> scanning through like 5-6 pages per search of results, I gave it up as a 
> lost cause.

Highly inexpert in C as I am, maybe I can come up with some examples 
that will be better than nothing. There's some info in the Friendly Manual:

http://www.nasm.us/doc/nasmdoc9.html#section-9.1

Chilling with the C lib - a.k.a. "just call printf" - is easy:

; nasm -f elf hwc.asm
; gcc hwc.o -o hwc
; ./hwc
; echo $? to see "answer"

global main
extern printf

section .data
     format_string db 'Hello, World!', 10, 0

section .text
     main:

     push format_string
     call printf
     add esp, 4 * 1

; "main" returns int (right???)
; zero is the usual "no error" exitcode, but
; return something "identifiable", just for fun
     mov eax, 42
     ret

Maybe a slightly less simple example would be better, showing multiple 
parameters... and a float - printing floats is the only time "just call 
printf" is worthwhile, IMO, and it isn't too intuitive...

; nasm -f elf hwfloat.asm
; gcc hwfloat.o -o hwfloat
; ./hwfloat
; echo $? to see "answer"

global main
extern printf

section .data
     hello_string db 'Hello, World!', 0
     the_int dd 42
     the_float dd 42.0  ; single precision

     format_string db 'The string is "%s"', 10
		db 'The float is: %f', 10
		db 'The int is: %d', 10, 0

section .text
     main:

; printf("the string is %s\nthe float is: %f\n the int is: %d",
;        hello_string, the_float, the_int);
;
; push rightmost parameter first...
     push dword [the_int]
; printf quietly promotes floats to doubles(!)
; so we'll want 8 bytes on the stack
     sub esp, 8

; now put our float there, as double
     fld dword [the_float]
     fstp qword [esp]
; and the leftmost parameter...
     push hello_string
; and the format string last
     push format_string
     call printf
     add esp, 4 * 3 + 8

; "main" returns int (right???)
; zero is the usual "no error" exitcode, but
; return something "identifiable", just for fun
     mov eax, 42

     ret


We can do "better" than this... defined as "less C"... by eliminating 
the "startup code" and putting "_start" back in our code. We don't need 
gcc at all - it only calls ld, since there's nothing to "compile". Maybe 
someday it will be "fixed", but last I checked, ld was expecting to use 
/lib/ld-linux.so.1 as a dynamic linker. This doesn't exist on my system, 
and doing "myprog" results in a "file not found" error, just as if 
"myprog" wasn't there!!! Highly mystifying! The "trick" is to tell ld to 
use /lib/ld-linux.so.2 with the "--dynamic-linker" or "-I" switch...

; nasm -f elf hwc3.asm
; ld hwc3.o -o hwc3 -lc -I/lib/ld-linux.so.2
; ./hwc3
; echo $? to see "answer"

global _start
extern printf

section .data
     format_string db 'Hello, World!', 10, 0

section .text
     _start:

     push format_string
     call printf
     add esp, 4 * 1

; zero is the usual "no error" exitcode, but
; return something "identifiable", just for fun
     mov ebx, 42
     mov eax, 1 ; __NR_exit
     int 80h

Note that, since _start isn't called, we can't exit with "ret"! I 
imagine using "exit()" would also work(?). Seems a little "shaky" to me, 
to be calling C library functions without running the C startup code, 
but it "seems to work". The only "gotcha" I've found is I can't find 
"stdin"/"stdout" - the "FILE *", not the integer STDIN/STDOUT - without 
gcc's help (haven't tried that hard). This can be important, since 
"printf" doesn't actually print anything until we flush the buffer! A 
linefeed will do it, or "fflush(stdin)"... These "high level" functions 
- fopen(), etc. - and including printf/scanf - work with buffered 
input/output, and are much faster (in some cases) than the low(er)-level 
  open(), read() etc. (if we *don't* do our own buffering, C can be faster!)

There generally isn't much advantage in calling the C library from an 
assembly program - might as well do the whole thing in C. More useful, 
generally, is to write routines in assembly   - faster existing routines 
(can be done, but "good luck") as you mention, or routines that don't 
yet exist in a C library ("good luck" again, I suspect) - to be called 
from C code.

The "Unix way" to find out about your CPU is to read /proc/cpuinfo (they 
make me say that). But getting info from cpuid (the instruction) might 
make an example of an asm function to be called from C - could be called 
from asm (or other), too, of course...

; nasm -f elf cpuvendor.asm
; nasm -f win32 --prefix _ cpuvendor.asm ???

; tell ld about us (via the .o file)
global cpu_vendor

cpu_vendor:
; C expects to have these regs preserved
     push edi
     push ebx
; our parameter, the buffer, is "up the stack",
; 4 for ebx, 4 for edi, 4 for return address = 12
     mov edi, [esp + 12]
     xor eax, eax
     cpuid
; with eax = 0, cpuid returns the vendor string
; in ebx, edx, ecx (why???), and the maximum level
; in eax (our return value). With eax greater than
; this maximum level (for this implementation of cpuid)
; cpuid returns unexpected results - 16 cores in this
; clunker? I don't think so!

; stuff the vendor string into our destination buffer
     mov [edi], ebx
     mov [edi + 4], edx
     mov [edi + 8], ecx
; don't forget to zero-terminate it!
     mov byte [edi + 12], 0
; restore caller's regs
     pop ebx
     pop edi
; we're done!
     ret

Assemble that first, then compile with "gcc -o getvendor getvendor.c 
cpuvendor.o" (probably want a -O2 or 3 switch in there - gcc produces 
some horrible code without any optimization - won't matter here)

#include <stdio.h>
int cpu_vendor(char *dest);

int main(){
     char buf[13];
     int cpuid_max_level;

     cpuid_max_level = cpu_vendor(buf);
     printf("vendor = %s\nmaxlevel = %d\n", buf, cpuid_max_level);
     return (0);
     };

Could go on to doing cpuid with eax 1, 2,... up to maxlevel, and print 
that info (which I'd have to look up), but... this has taken long 
enough. It's a start...

Best,
Frank

Re: [Nasm-users] a quick question:

[Frank K. <fbk...@zy...>]

Tyler Littlefield wrote:
> Hello,
> I'm going to try to write a "guess the number." tyep program.
> First, I wrote this, so I could link to it:
> #include <cmath>
> #include <ctime>
> #include <cstdlib>
> int rnum();
> int rnum()
> {
> srand(time(NULL));

I think you want to only do this once.

> return (rand()%10);
> }
> I'm also going to have to write a rapper for itoa.
> next, my asm program so far is as follows:
> global _start
> section .text
> welcome db "Welcome to guess the number!",10,"Written by Tyler Littlefield 
> <ty...@ty...>",10,10
> welcomelen equ $-welcome
> texta db "I am thinking of a number between 1 and 10.",10,"Can you guess it 
> in three tries?",10
> textalen equ $-texta
> section .data

You've got "section .text" and "section .data" swapped!!!

> nop
> _start:
> nop
> mov eax,4
> mov ebx,1
> mov ecx,welcome
> mov edx,welcomelen
> int 80h
> mov eax,4
> mov ebx,1
> mov ecx,texta
> mov edx,textalen
> int 80h
> when I compile with nasm, that works great. but when I gcc ns.o rand.o it 
> gives errors about _start,

"_start" exists in the C "startup" code (crt0.o?), and we only want one 
- this calls "main", so start your asm code with "main" nd has to be 
declared global), not "_start". Or link with "ld -o myprog ns.o rand.o 
-I/lib/ld-linux.so2 -lc".

> and then says it can't find time and srand and 
> rand.
> Ideas?

Dunno about that one. I thought those were "standard"... shouldn't need 
underscores... Dunno. Jeff Duntemann's got a "rand()" example in 
linuxcode.zip from:

http://www.copperwood.com/pub/

I'm "working on" (figure of speech) a reply from a couple messages ago 
with a few simple C/asm examples... I'll get back to ya "real soon now"...

(incidentally, to reply to this list, hit "reply all" - just "reply" 
replies only to the sender - I'm not sure the message I refer to 
actually made it to the list...)

I'll get back to ya - and see my post on the forum... might help...

Best,
Frank

[Nasm-users] a quick question:

[Tyler L. <ty...@ty...>]

Hello,
I'm going to try to write a "guess the number." tyep program.
First, I wrote this, so I could link to it:
#include <cmath>
#include <ctime>
#include <cstdlib>
int rnum();
int rnum()
{
srand(time(NULL));
return (rand()%10);
}
I'm also going to have to write a rapper for itoa.
next, my asm program so far is as follows:
global _start
section .text
welcome db "Welcome to guess the number!",10,"Written by Tyler Littlefield 
<ty...@ty...>",10,10
welcomelen equ $-welcome
texta db "I am thinking of a number between 1 and 10.",10,"Can you guess it 
in three tries?",10
textalen equ $-texta
section .data
nop
_start:
nop
mov eax,4
mov ebx,1
mov ecx,welcome
mov edx,welcomelen
int 80h
mov eax,4
mov ebx,1
mov ecx,texta
mov edx,textalen
int 80h
when I compile with nasm, that works great. but when I gcc ns.o rand.o it 
gives errors about _start, and then says it can't find time and srand and 
rand.
Ideas?


Thanks,
Tyler Littlefield
email: ty...@ty...
web: tysdomain-com
Visit for quality software and web design.
skype: st8amnd2005

Re: [Nasm-users] help with linking?

[H. P. A. <hp...@zy...>]

Tyler Littlefield wrote:
> Hello,
> I was wondering how a linking of nasm to other libraries could be pulled
> off.
> I've wanted to use functions from other libraries, such as math.h (pow) etc,
> but am not sure how to link--ideas would be great.

It depends on the operating system.

On Unix operating systems, or on Windows using MinGW, the easiest way is
to use your C compiler to link:

cc -o output input1.o input2.o [-library]

The stanadard library, libc, is automatically linked in, other libraries
you have to specify.

This will also cause the C library startup code to be included, which is
necessary in order to invoke arbitrary functions.

	-hpa

[Nasm-users] help with linking?

[Tyler L. <ty...@ty...>]

Hello,
I was wondering how a linking of nasm to other libraries could be pulled
off.
I've wanted to use functions from other libraries, such as math.h (pow) etc,
but am not sure how to link--ideas would be great.


Thanks,
Tyler Littlefield
email: ty...@ty...
web: tysdomain-com
Visit for quality software and web design.
skype: st8amnd2005

Re: [Nasm-users] code problems--relatively new

[Frank K. <fbk...@zy...>]

Tyler Littlefield wrote:
> hello,
> thanks a lot for the help, and sorry for the delayed reply.

No rush...

> I've got a couple questions, though.
> I kinda wanted to just work out the length rather than having a ton of 
> constants declared. Especially when I start writing code that requires 
> that the program be small enough, such as a boot loader, etc.
> Can you suggest a more efficient way of doing things?

Declaring constants won't add anything to the size of the code. You not 
only save the "logic" for finding the zero - you save the zero! Compare:

msg db "Hello world", 10
msg_len equ $ - msg
...

mov ecx, msg
mov edx, msg_len
...

With:

msg db "Hello world!", 10, 0
...

mov ecx, msg
xor edx, edx ; get length in edx
.getlen:
cmp byte [ecx + edx], 0
jz .gotlen
inc edx
jmp .getlen
.gotlen:
...


> I'd also thought it might be needed when reading user data, or printing 
> other strings.

Reading user data (with sys_read) returns the number of bytes read, but 
those "other strings" are likely to be zero-terminated. You can "just 
call strlen", of course. That'll require linking in code for the dynamic 
loader. It'll return the length in eax... I think I like the "inline" 
way better...

> I'm relatively new to this, so have some idea what you just did, but you 
> lost me with your esp. :)

Maybe I "got ahead of myself". :)

> Also, was there a reason for the 'nop' instruction?

Yeah... sort of. It serves as a "parking place for gdb". Gdb is happier 
stepping through your code from the beginning if there's a one-byte 
instruction first. Doesn't really need to be there.

Lemme try this "esp thing" with a few more comments... I showed you a 
thing that used the stack as a "buffer" to print a single character, and 
you said...

>>> So, I would send "hello world." to the stack, then pop it off in the 
>>> write func and use the strlen for edx.

You could copy the whole "hello world" string to the stack and print it 
from there, but the "usual" way would be to pass the address of the 
string on the stack. But you can't really "pop" it off in the 
function... the "call" instruction uses the stack to store the return 
address...

>> global _start
>>
>> section .data
>> msg db "Hello world!", 10, 0
>>
>> section .text
>> _start:
>> nop
>> push msg

Since the stack starts at a high memory address and works down, this 
subtracts 4 from esp, and puts the address of "msg" in memory at 
[ss:esp] (ss is the default segment for esp... and ebp... so you 
wouldn't write it in your code, but it's still part of the address).

>> call print_zero_terminated_string

This subtracts another 4 from esp, and puts the return address (the 
address of the "add" instruction) at [ss:esp]... but the "ret" removes 
it, and adds the 4 back on. But we've still got the parameter on the 
stack, so...

>> add esp, 4

We could have "pop"ped a dummy register, too. In fact, since we're just 
exiting, we didn't really need to clean up the stack at all... but it's 
a good idea...

>> ...
>> mov eax, 1
>> int 80h
>>
>> print_zero_terminated_string:

When we get here, the return address is at [esp], the first parameter is 
at [esp + 4] (if we had more parameters, they'd be at [esp + 8], [esp + 
12], etc.).

It is also common to do:

push ebp ; save caller's ebp
mov ebp, esp ; use ebp for a "stack frame pointer"
...
Now the first parameter is at [ebp + 8], we can subtract something from 
esp to make a place for temporary variables, and the parameters and 
local variables are at constant offsets from ebp, no matter what we do 
with esp... and before the "ret" we need to:

mov esp, ebp
pop ebp
...

There are advantages to that, but we didn't do it that way, so...

>> mov ecx, [esp + 4] ; buffer in ecx
>> xor edx, edx ; get length in edx
>> .getlen:
>> cmp byte [ecx + edx], 0
>> jz .gotlen
>> inc edx
>> jmp .getlen
>> .gotlen:
>> mov ebx, 1 ; stdout
>> mov eax, 4 ; __NR_write
>> int 80h

When we get to the "ret", esp had *better* be pointed to the return address!

>> ret

Hope that makes the esp part clearer...

Best,
Frank

Re: [Nasm-users] code problems--relatively new

[Frank K. <fbk...@zy...>]

Tyler Littlefield wrote:
> hello,
> thanks; I'll do that.
> I'd origenally wanted to  do a strlen type thing, and then just put the 
> message or something in, and then run the call, so that I wouldn't have 
> to define messages for everything in the .data, if there would be an 
> efficient way of doing it.
> So, I would send "hello world." to the stack, then pop it off in the 
> write func and use the strlen for edx.

Something like?

global _start

section .data
	msg db "Hello world!", 10, 0

section .text
_start:
	nop
	push msg
	call print_zero_terminated_string
	add esp, 4
	...
	mov eax, 1
	int 80h

print_zero_terminated_string:
	mov ecx, [esp + 4] ; buffer in ecx
	xor edx, edx ; get length in edx
.getlen:
	cmp byte [ecx + edx], 0
	jz .gotlen
	inc edx
	jmp .getlen
.gotlen:
	mov ebx, 1 ; stdout
	mov eax, 4 ; __NR_write
	int 80h
	ret


Of course, Nasm will calculate the length for you...

msg db "Hello world", 10
msg_len equ $ - msg

...saving you having to walk down the string byte-by-byte looking for 
the zero. There's an algorithm around for scanning a string a dword at a 
time - worthwhile if you've got long strings, or a lot of them - but 
it's long and complicated. Fastest way is to not do it. If you're 
interfacing with C, you may be stuck with zero-terminated strings, but 
it isn't the most efficient data structure...

Or maybe that's not what you had in mind...

Best,
Frank

Re: [Nasm-users] code problems--relatively new

[Frank K. <fbk...@zy...>]

Tyler Littlefield wrote:
> Hello,
> I've spent the last couple hours trying to debug this, and haven't found 
> much.
> I"m writing a proc that would take what is in eax, and run through that and 
> print byte-by-byte the message supplied in eax,
> here's the code--assistance would be awesome if possible.
> section .data
> buff db "Hello world!",0 ;the message we're going to print
> section .text
> global _start:
> _start:
> mov eax,buff ;moves the buffer address to eax for the call.
> call write ;will write what ever is stored at eax byte by byet.
> call exit ;exits
> 
> write:
> mov esi,eax ;get what's stored in eax (hopefully an address) and store it in 
> esi.
> jmp .wloop
> .wloop: ;the loop.
> call pc
> mov cl,[esi] ;moves the dereferenced esi to cl.
> movzx ecx, byte [esi]
> cmp cl,0 ;is the byte a null character?

This is okay... but for sys_write, you want the address of what to print 
in ecx, not "the character". So...

mov ecx, esi

> je .wend
> mov eax,4
> mov ebx,1
> mov edx,1
> int 80h ;print the character.
> inc esi ;move the pointer to the next char in the buffer.
> jmp .wloop ;restart the loop
> .wend:
> ret
> 
> exit:
> mov eax,1
> mov ebx,1
> int 80h
> ret
> 
> pc:
> mov eax,4
> mov ebx,1
> mov ecx,'d'

Likewise, this isn't going to work...

> mov edx,1
> int 80h
> ret
> 
> Thanks,
> Tyler Littlefield
> email: ty...@ty...
> web: tysdomain-com
> Visit for quality software and web design.
> skype: st8amnd2005

Calling the kernel for each character is horribly inefficient, but if 
that's what you wanna do... the single change above should fix it. You 
could do "cmp byte [esi], 0" to see if you're at the end of the string, 
and avoid putting "the character" in cl to "cmp"...

Likewise, putting "d" in ecx will segfault. The "d' wants to be in a 
buffer, and ecx the address of the buffer. We can use the stack for our 
"buffer"...

push 'd'
mov ecx, esp
mov edx, 1 ; (one character)
mov ebx, 1 ; (stdout)
mov eax, 4 ; (__NR_write)
int 80h
add esp, 4 ; (clean up stack!)
...

Or something like that...

Best,
Frank

[Nasm-users] code problems--relatively new

[Tyler L. <ty...@ty...>]

Hello,
I've spent the last couple hours trying to debug this, and haven't found 
much.
I"m writing a proc that would take what is in eax, and run through that and 
print byte-by-byte the message supplied in eax,
here's the code--assistance would be awesome if possible.
section .data
buff db "Hello world!",0 ;the message we're going to print
section .text
global _start:
_start:
mov eax,buff ;moves the buffer address to eax for the call.
call write ;will write what ever is stored at eax byte by byet.
call exit ;exits

write:
mov esi,eax ;get what's stored in eax (hopefully an address) and store it in 
esi.
jmp .wloop
.wloop: ;the loop.
call pc
mov cl,[esi] ;moves the dereferenced esi to cl.
movzx ecx, byte [esi]
cmp cl,0 ;is the byte a null character?
je .wend
mov eax,4
mov ebx,1
mov edx,1
int 80h ;print the character.
inc esi ;move the pointer to the next char in the buffer.
jmp .wloop ;restart the loop
.wend:
ret

exit:
mov eax,1
mov ebx,1
int 80h
ret

pc:
mov eax,4
mov ebx,1
mov ecx,'d'
mov edx,1
int 80h
ret

Thanks,
Tyler Littlefield
email: ty...@ty...
web: tysdomain-com
Visit for quality software and web design.
skype: st8amnd2005

Re: [Nasm-users] Preventing macro name expansion

[H. P. A. <hp...@zy...>]

Frank Kotler wrote:
> 
> Unfortunately, I don't know the answer to your question. Possibly 
> "%ifidni" instead of "%ifdef" would get rid of the "identifier 
> expected"??? I haven't had a chance to try this out... I'm not sure if 
> there's a way to do what (I think) you want... Must be...
> 

%ifdef, for obvious reasons, do not expand macros in its argument, so 
"FlagVal %+ %1" probably ends up with either nonsense or something like 
"FlagVal%1", neither of which is what is desired here.

I think a much easier way to do what the original poster wants is 
probably to use equates:

%define NextFlagEnum 1
%macro FlagEnum 1.nolist
FlagVal. %+ %1	equ NextEnum
%assign	NextFlagEnum NextFlagEnum+1
%endmacro

Since equates are symbols, not macros, NASM will do the erroring out for 
duplicate definitions.

	-hpa

Re: [Nasm-users] Preventing macro name expansion

[Frank K. <fbk...@zy...>]

Ermin Robert Alegrid wrote:
> Is there a way to stop a (single line) macro name from being expanded? I'm writing macros which create other macros, whose names are built up using the %+ operator, and I want to be able to test if a macro with the same name exists or possibly redefine it.
> 
> I've tried something similar to the following, but it's not working (a bunch of errors saying %xdefine and %ifdef expect identifiers, so I assume that means that it expanded the name passed to it before testing):
> 
> %macro DefMac 2.nolist
> 	%xdefine %1 %2
> %endmacro
> 
> %define LastNum 1
> %macro FlagEnum 1.nolist
> 	%warning Defining FlagVal. %+ %1
> 	%ifdef FlagVal. %+ %1
> 		%warning FlagVal. %+ %1 Redefined
> 	%endif
> 	DefMac FlagVal. %+ %1, LastNum
> 	%assign LastNum LastNum << 1
> %endmacro
> 
> FlagEnum A
> FlagEnum B
> FlagEnum C
> ; ...
> FlagEnum A
> 
> ; ... there a way to stop a (single line) macro name from being expanded? I'm writing macros which create other macros, whose names are built up using the %+ operator, and I want to be able to test if a macro with the same name exists or possibly redefine it.
> 
> I've tried something similar to the following, but it's not working (a bunch of errors saying %xdefine and %ifdef expect identifiers, so I assume that means that it expanded the name passed to it before testing):
> 
> %macro DefMac 2.nolist
> 	%xdefine %1 %2
> %endmacro
> 
> %define LastNum 1
> %macro FlagEnum 1.nolist
> 	%warning Defining FlagVal. %+ %1
> 	%ifdef FlagVal. %+ %1
> 		%warning FlagVal. %+ %1 Redefined
> 	%endif
> 	DefMac FlagVal. %+ %1, LastNum
> 	%assign LastNum LastNum << 1
> %endmacro
> 
> FlagEnum A
> FlagEnum B
> FlagEnum C
> ; ...
> FlagEnum A
> 
> ; .
> --------------------------------------------
> Robert Alegrid
> #3164658
> BP 079 Physics

Hi Robert,

Thank you! Since we put the list on a "moderated" basis to eliminate 
spam, this is the first message I've been able to *approve*!

Unfortunately, I don't know the answer to your question. Possibly 
"%ifidni" instead of "%ifdef" would get rid of the "identifier 
expected"??? I haven't had a chance to try this out... I'm not sure if 
there's a way to do what (I think) you want... Must be...

Best,
Frank

[Nasm-users] Preventing macro name expansion

[Ermin R. A. <e.a...@st...>]

Is there a way to stop a (single line) macro name from being expanded? I'm writing macros which create other macros, whose names are built up using the %+ operator, and I want to be able to test if a macro with the same name exists or possibly redefine it.

I've tried something similar to the following, but it's not working (a bunch of errors saying %xdefine and %ifdef expect identifiers, so I assume that means that it expanded the name passed to it before testing):

%macro DefMac 2.nolist
	%xdefine %1 %2
%endmacro

%define LastNum 1
%macro FlagEnum 1.nolist
	%warning Defining FlagVal. %+ %1
	%ifdef FlagVal. %+ %1
		%warning FlagVal. %+ %1 Redefined
	%endif
	DefMac FlagVal. %+ %1, LastNum
	%assign LastNum LastNum << 1
%endmacro

FlagEnum A
FlagEnum B
FlagEnum C
; ...
FlagEnum A

; ... there a way to stop a (single line) macro name from being expanded? I'm writing macros which create other macros, whose names are built up using the %+ operator, and I want to be able to test if a macro with the same name exists or possibly redefine it.

I've tried something similar to the following, but it's not working (a bunch of errors saying %xdefine and %ifdef expect identifiers, so I assume that means that it expanded the name passed to it before testing):

%macro DefMac 2.nolist
	%xdefine %1 %2
%endmacro

%define LastNum 1
%macro FlagEnum 1.nolist
	%warning Defining FlagVal. %+ %1
	%ifdef FlagVal. %+ %1
		%warning FlagVal. %+ %1 Redefined
	%endif
	DefMac FlagVal. %+ %1, LastNum
	%assign LastNum LastNum << 1
%endmacro

FlagEnum A
FlagEnum B
FlagEnum C
; ...
FlagEnum A

; .
--------------------------------------------
Robert Alegrid
#3164658
BP 079 Physics

[Nasm-users] Nasm 2.05rc1 released

[Frank K. <fbk...@ve...>]

Nasm 2.05rc1 is available at SourceForge.

<http://sourceforge.net/project/showfiles.php?group_id=6208>

Alternate (new!!!) address:

http://www.nasm.us/

I failed to get 2.04rc2 through 2.04rc6 up at SourceForge, and as a 
result of not enough testing, 2.04 turned out to *not* be a "candidate" 
after all. :(

We hope our users will help us test this "release candidate" so it 
doesn't happen again! Partial changelog follows. (this is now Appendix C 
in the Nasm Manual)

Best,
Frank

  C.1.1 Version 2.05

        (*) Fix redundant REX.W prefix on `JMP reg64'.

        (*) Make the behaviour of `-O0' match NASM 0.98 legacy behavior. See
            section 2.1.22.

        (*) `-w-user' can be used to suppress the output of `%warning'
            directives. See section 2.1.24.

        (*) Fix bug where `ALIGN' would issue a full alignment datum instead
            of zero bytes.

        (*) Fix offsets in list files.

        (*) Fix `%include' inside multi-line macros or loops.

  C.1.2 Version 2.04

        (*) Sanitize macro handing in the `%error' directive.

        (*) New `%warning' directive to issue user-controlled warnings.

        (*) `%error' directives are now deferred to the final assembly
            phase.

        (*) New `%fatal' directive to immediately terminate assembly.

        (*) New `%strcat' directive to join quoted strings together.

        (*) New `%use' macro directive to support standard macro directives.
            See section 4.6.4.

        (*) Excess default parameters to `%macro' now issues a warning by
            default. See section 4.3.

        (*) Fix `%ifn' and `%elifn'.

        (*) Fix nested `%else' clauses.

        (*) Correct the handling of nested `%rep's.

        (*) New `%unmacro' directive to undeclare a multi-line macro. See
            section 4.3.10.

        (*) Builtin macro `__PASS__' which expands to the current assembly
            pass. See section 4.11.9.

        (*) `__utf16__' and `__utf32__' operators to generate UTF-16 and
            UTF-32 strings. See section 3.4.5.

        (*) Fix bug in case-insensitive matching when compiled on platforms
            that don't use the `configure' script. Of the official release
            binaries, that only affected the OS/2 binary.

        (*) Support for x87 packed BCD constants. See section 3.4.7.

        (*) Correct the `LTR' and `SLDT' instructions in 64-bit mode.

        (*) Fix unnecessary REX.W prefix on indirect jumps in 64-bit mode.

        (*) Add AVX versions of the AES instructions (`VAES'...).

        (*) Fix the 256-bit FMA instructions.

        (*) Add 256-bit AVX stores per the latest AVX spec.

        (*) VIA XCRYPT instructions can now be written either with or
            without `REP', apparently different versions of the VIA spec
            wrote them differently.

        (*) Add missing 64-bit `MOVNTI' instruction.

        (*) Fix the operand size of `VMREAD' and `VMWRITE'.

        (*) Numerous bug fixes, especially to the AES, AVX and VTX
            instructions.

        (*) The optimizer now always runs until it converges. It also runs
            even when disabled, but doesn't optimize. This allows most
            forward references to be resolved properly.

  C.1.3 Version 2.03.01

        (*) Fix buffer overflow in the listing module.

        (*) Fix the handling of hexadecimal escape codes in `...` strings.

        (*) The Postscript/PDF documentation has been reformatted.

        (*) The `-F' option now implies `-g'.

  C.1.4 Version 2.03

        (*) Add support for Intel AVX, CLMUL and FMA instructions, including
            YMM registers.

        (*) `dy', `resy' and `yword' for 32-byte operands.

        (*) Fix some SSE5 instructions.

        (*) Intel `INVEPT', `INVVPID' and `MOVBE' instructions.

        (*) Fix checking for critical expressions when the optimizer is
            enabled.

        (*) Support the DWARF debugging format for ELF targets.

        (*) Fix optimizations of signed bytes.

        (*) Fix operation on bigendian machines.

        (*) Fix buffer overflow in the preprocessor.

        (*) `SAFESEH' support for Win32, `IMAGEREL' for Win64 (SEH).

        (*) `%?' and `%??' to refer to the name of a macro itself. In
            particular, `%idefine keyword $%?' can be used to make a keyword
            "disappear".

        (*) New options for dependency generation: `-MD', `-MF', `-MP',
            `-MT', `-MQ'.

        (*) New preprocessor directives `%pathsearch' and `%depend'; INCBIN
            reimplemented as a macro.

        (*) `%include' now resolves macros in a sane manner.

        (*) `%substr' can now be used to get other than one-character
            substrings.

        (*) New type of character/string constants, using backquotes
            (``...`'), which support C-style escape sequences.

        (*) `%defstr' and `%idefstr' to stringize macro definitions before
            creation.

        (*) Fix forward references used in `EQU' statements.

[Nasm-users] Nasm 2.03.01 released on SourceForge

[Frank K. <fbk...@zy...>]

Nasm 2.03.01 has been released on SourceForge:

<http://sourceforge.net/project/showfiles.php?group_id=6208>

This is a bugfix release, and it *does* repair a buffer overflow. You 
might want to upgrade. Big thanks to H. Peter Anvin (of iPath, Inc) for 
getting on top of this!

Also, "-F" implies "-g". We no longer have to use both.

Best,
Frank

Re: [Nasm-users] [Nasm-devel] Release date for 2.03

[Frank K. <fbk...@co...>]

Frank Kotler wrote:
> H. Peter Anvin wrote:
>   
>> Okay, corrected binaries for 2.03 now available.
>>     
>
> Still no joy on uploading 'em to SoreFog.

Fixed. (duplicate message to test list mail...)

Best,
Frank

Re: [Nasm-users] [Nasm-devel] Release date for 2.03

[Frank K. <fbk...@co...>]

Frank Kotler wrote:
> H. Peter Anvin wrote:
>   
>> Okay, corrected binaries for 2.03 now available.
>>     
>
> Still no joy on uploading 'em to SoreFog.

Fixed! Now available on SF too. Thanks for your patience.

Best,
Frank

[Nasm-users] Macros for filenames

[H. P. A. <hp...@zy...>]

I just discovered something very disturbing...

To use macros in filenames, one has to do:

%define Foo foo.inc
%include "Foo"

... as opposed to the saner ...

%define Foo "foo.inc"
%include Foo

Does anyone think this is anything other than a bug that should be 
fixed?  I have a specific reason: I wanted to create directives to do 
path search and to inject dependency information.  Basically, it can be 
used to redefine incbin as a macro which also produce dependency 
information.

	-hpa

Re: [Nasm-users] Talk, don't spam

[Frank K. <fbk...@ve...>]

H. Peter Anvin wrote:
> Frank Kotler wrote:
> 
>>That's the option I was looking for. I'll look again. What I've done 
>>seems to be asking me for approval after the fact...
> 
> That's what "moderation" means...

After they post it they ask me if it's okay??? That's *not* what's 
happening... I just saw the "reply to poster" from you well before I got 
the "message waits your approval" on the "reply to list", and Thought* 
that's what they were doing.

Anyway... bad idea, I'll undo it and look more for that "subscribers 
only" option... I think I just screwed up! I got a "waits your approval" 
on two messages - one from you, and one selling watches. I intended to 
approve one and reject the other... but I haven't seen the one from you 
show up. Maybe they're just slow... But I think I blew it somehow. :(

>>On a completely different topic, but still "talk", I'm wondering if you, 
>>or someone, can help me. There's an issue come up on alt.lang.asm (yeah, 
>>I know...) under the subject "Why is my nasm program killing itself". A 
>>guy has got Slackware 12.0 - kernel 2.6.21.5, apparently, and is having 
>>apparently good programs being "killed". Looks like they're killing the 
>>loader, actually... His disassembly suggests it's not a Nasm or ld 
>>problem...
>>
>>We saw something in kernels 2.6.10 - 2.6.16 (approximately) where 
>>programs without a writeable section last were causing a SIGSEGV in the 
>>loader (fs/binfmt_elf.c, IIRC) - original patch threw SIGKILL. I suspect 
>>something similar here.
> 
> Well, I can't even log into Usenet at this time, it seems.

Okay. I probably shouldn't have pestered you with it anyway. I thought 
you might know a "workaround" I could tell the guy. So far, it looks 
like just not having a .bss at all is working for him.

Looking at the loader in 2.6.23.9 (the latest one he encountered the 
problem on), I see several places we could get killed. Since it seems 
.bss might have something to do with it, I'm suspicious of this one...

...
if (unlikely (elf_brk > elf_bss)) {
			unsigned long nbyte;
	
			/* There was a PT_LOAD segment with p_memsz > p_filesz
			   before this one. Map anonymous pages, if needed,
			   and clear the area.  */
			retval = set_brk (elf_bss + load_bias,
					  elf_brk + load_bias);
			if (retval) {
				send_sig(SIGKILL, current, 0);
				goto out_free_dentry;
			}
...

... but I'm not "oriented" enough to know if we even hit that code, much 
less what to do to avoid it. Quite possibly a red herring... I'll study 
it some more (ought to anyway), but I don't have a lot of hope...

Meantime... if anyone is seeing mysterious kills... try removing .bss 
(if any), and see if that helps... and let me know, I guess, so I can 
advise the guy. Or, if anyone knows on which kernel this *stopped* 
happening... (I understand it's been "fixed", but can't confirm it), I'd 
pass that info along, too...
		
Sorry I deleted your message... as appears to have happened... could ya 
repost?

Best,
Frank

Re: [Nasm-users] Talk, don't spam

[H. P. A. <hp...@zy...>]

Frank Kotler wrote:
> 
> That's the option I was looking for. I'll look again. What I've done 
> seems to be asking me for approval after the fact...
> 

That's what "moderation" means...

> On a completely different topic, but still "talk", I'm wondering if you, 
> or someone, can help me. There's an issue come up on alt.lang.asm (yeah, 
> I know...) under the subject "Why is my nasm program killing itself". A 
> guy has got Slackware 12.0 - kernel 2.6.21.5, apparently, and is having 
> apparently good programs being "killed". Looks like they're killing the 
> loader, actually... His disassembly suggests it's not a Nasm or ld 
> problem...
> 
> We saw something in kernels 2.6.10 - 2.6.16 (approximately) where 
> programs without a writeable section last were causing a SIGSEGV in the 
> loader (fs/binfmt_elf.c, IIRC) - original patch threw SIGKILL. I suspect 
> something similar here.

Well, I can't even log into Usenet at this time, it seems.

	-hpa