nasm-users — Discussion and help for Nasm users.

[Nasm-users] Announcing NASM 2.15

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

After some 18 months of development, I hereby announce the release of
NASM 2.15, available at:

	https://nasm.us/

The list of improvements are too numerous to count, but as always, a
summary is at:

	https://nasm.us/doc/nasmdocc.html

The number of people who have helped with development, bug reports,
testing, and technical assistance is far too long to mention, but huge
thanks to all of you.

As always, if you find any problems with this release, please file a bug
report, preferably including a test case, at:

	https://bugzilla.nasm.us/

Even if we are unable to respond right away, we do work through this bug
list over time.


If you are receiving this message through the mailing lists on
Sourceforge, please note that the Sourceforge lists have been deprecated
in favor of our own mail server:

	https://lists.nasm.us/

Please subscribe to the new mailing lists as soon as possible;
Sourceforge does not allow even administrators to extract the list of
subscribers, so you will need to resubscribe manually.

Enjoy!

	-hpa

Re: [Nasm-users] Suggestion: Limit instruction set to specific CPU type

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

On 11/21/2011 10:36 AM, H. Peter Anvin wrote:
> 
> Yes, it would be great to have.  Looking forward to your patch.
> 

Note: the "CPU" directive already exists, although it is limited in its
support for recent machines.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [Nasm-users] Suggestion: Limit instruction set to specific CPU type

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

On 11/11/2011 09:02 AM, Philipp Kloke wrote:
> Hi,
>  
> I would like to suggest to add a –cpu option to the command line flags
> of nasm (somewhat similar to GCCs –march option) where the user can
> specify the CPU type he is programming for. If the user uses an
> instruction that is not supported by the CPU, the assembler can warn
> about this. This can help to keep code running on old machines.
>  
> What do you think about this?
>  

Yes, it would be great to have.  Looking forward to your patch.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [Nasm-users] libraries

[Jakob B. <jb...@wi...>]

On 11/3/2011 7:12 AM, Hugh Aguilar wrote:
> Hello. I'm starting a project that will be written in assembly 
> language. I had intended to use HLA, but I can't get on their mailing 
> list, and I'm hesitant to commit to using HLA without live support --- 
> that is why I'm considering NASM now.
>
> What had impressed me about HLA was that it comes with a large 
> library, and that programs can assemble for either Windows or Linux so 
> long as the programs restrict themselves to using this library. Is 
> there anything like that for NASM? Specifically, for console 
> interface, file access and serial communication? It may be too 
> complicated to support both Windows and Linux, in which case I will 
> support Linux --- but it would be nice to support both.
>
I don't know, maybe others on the list do
> Also, other than the Windows/Linux issue, I was impressed with HLA's 
> library in general. Are there any libraries of NASM code available? I 
> would be interested in basic data-structure support (lists, arrays, 
> associative arrays, etc.), such as I provided in my Forth novice package:
> http://www.forth.org/novice.html
> Is there a repository of NASM code somewhere?
>
I don't know either, maybe others can respnd to that
> Does NASM work with any debugger, such as GDB?
When assembling for Linux Elf, Nasm can generate STABS and DWARD debug 
information, which I think is what GDB wants.
>
> Is NASM source-code available, and if so, is it BSD or GPL license? 
> What language is it written in?
>
Yes, It is simple BSD, source is available from the main download page 
http://nasm.us/

[Nasm-users] Suggestion: Limit instruction set to specific CPU type

[Philipp K. <phi...@we...>]

Hi,

I would like to suggest to add a –cpu option to the command line flags of nasm (somewhat similar to GCCs –march option) where the user can specify the CPU type he is programming for. If the user uses an instruction that is not supported by the CPU, the assembler can warn about this. This can help to keep code running on old machines.

What do you think about this?


Philipp

[Nasm-users] libraries

[Hugh A. <hug...@ya...>]

Hello. I'm starting a project that will be written in assembly language. I had intended to use HLA, but I can't get on their mailing list, and I'm hesitant to commit to using HLA without live support --- that is why I'm considering NASM now.

What had impressed me about HLA was that it comes with a large library, and that programs can assemble for either Windows or Linux so long as the programs restrict themselves to using this library. Is there anything like that for NASM? Specifically, for console interface, file access and serial communication? It may be too complicated to support both Windows and Linux, in which case I will support Linux --- but it would be nice to support both.

Also, other than the Windows/Linux issue, I was impressed with HLA's library in general. Are there any libraries of NASM code available? I would be interested in basic data-structure support (lists, arrays, associative arrays, etc.), such as I provided in my Forth novice package:
http://www.forth.org/novice.html

Is there a repository of NASM code somewhere?

Does NASM work with any debugger, such as GDB?

Is NASM source-code available, and if so, is it BSD or GPL license? What language is it written in?

Thanks for your help --- Hugh

Re: [Nasm-users] linking nasm programs to windows libraries

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

Littlefield, Tyler wrote:
> Hello all:
> I am writing a couple nasm functions to test this out with, and have 
> been experiencing a problem. I want to link my nasm program to 
> user32.lib, which I have done, but when I use the microsoft visual 
> studio link command with user32.lib, I still get told that MessageBoxA 
> is undefined. How do I do this?

Hi Tyler,

Just a WAG, but try _MessageBoxA@16

> I am aware of alink, but it seems to be a work in progress and I'd 
> rather just link to the normal libraries if I possibly can; help is 
> appreciated.

Not a whole lot of progress lately on Alink, AFAIK. There's an IDE and 
linker (based on Alink, I think) here:

http://www.nasmide.co.nr/

This is a "work in progress", under active development (and looking for 
developers), so it may not be what you want, but I thought I'd mention 
it. If you try it (anyone), let us know what you think.

Best,
Frank

[Nasm-users] linking nasm programs to windows libraries

[Littlefield, T. <ty...@ty...>]

Hello all:
I am writing a couple nasm functions to test this out with, and have 
been experiencing a problem. I want to link my nasm program to 
user32.lib, which I have done, but when I use the microsoft visual 
studio link command with user32.lib, I still get told that MessageBoxA 
is undefined. How do I do this?

I am aware of alink, but it seems to be a work in progress and I'd 
rather just link to the normal libraries if I possibly can; help is 
appreciated.
Thanks in advance,

-- 

Take care,
Ty
my website:
http://tds-solutions.net
my blog:
http://tds-solutions.net/blog
skype: st8amnd127
My programs don't have bugs; they're randomly added features!

Re: [Nasm-users] macro variables in labels? strange problem!

[Per J. <pe...@co...>]

Frank Kotler wrote:
> Hi Per,
> Hi List,
> 
> As "owner" of this list, I got the following...
> 
>> As list administrator, your authorization is requested for the
>> following mailing list posting:
> 
> blah, blah, blah...
> 
> But when I logged in to approve it, I was informed that there were "no 
> pending requests". Did you "cancel" it somehow, Per? (how?) Or is SF 
> just messin' with me (us)? 

Hi Frank

yes I can cancelled it - I worked out the answer myself.

>> I'm trying generate labels using a macro, e.g. like this:
>>
>>    %macro blop 1
>>    %assign n 0
>>
>>    %rep %1
>>    %assign n n+1
>> label_n:
>>    somecode
>>       %endrep
>>
>>    %endmacro
>>
>> I was hoping to end up with a set of labels
>>
>> label_1:
>>    somecode
>> label_2:
>>    somecode
>> etcetera
>>
>> I'm feeling pretty stupid having to ask, but how do I get the
>> variable 'n' expanded in(to) the label?
> 
> It's a better question than it might seem at first! At one time, in some 
> cases, Nasm would have done what you want. But it's been "tightened up" 
> in recent versions, and you really need to use the "%+" operator!

Ah, thanks - my solition was to use

label_%[n]

which also worked. I like %+n better though.

>> Later I also want to generate:
>>
>> global  label_n:func
>> lenlab_n    db      *-label_n
>>
>> (with 'n' being my variable).
> 
> I suspect you want '$', not '*'. The '$' is evaluated where it occurs, 
> so this length calculation needs to be done right after the "label" 

Yep, the '*' was a typo ('*' is used as location counter in S390 assembler, iirc).

> FWIW, I created this list at the request of another developer, to keep 
> this kind of question off the "developer's list". It gets very little 
> traffic. There's the "Nasm Forum" here:
> 
> http://forum.nasm.us
> 
> which is also suitable for this kind of question. You might get better 
> results there.

I'm too lazy to use forums - I sometimes post a question, but then I forget
where I posted it ....


/Per

[Nasm-users] macro variables in labels? strange problem!

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

Hi Per,
Hi List,

As "owner" of this list, I got the following...

> As list administrator, your authorization is requested for the
> following mailing list posting:

blah, blah, blah...

But when I logged in to approve it, I was informed that there were "no 
pending requests". Did you "cancel" it somehow, Per? (how?) Or is SF 
just messin' with me (us)? Well, I'll attempt to "answer" it anyhow! :)

> I'm trying generate labels using a macro, e.g. like this:
> 
>    %macro blop 1
>    %assign n 0
> 
>    %rep %1
>    %assign n n+1
> label_n:
>    somecode
>    
>    %endrep
> 
>    %endmacro
> 
> I was hoping to end up with a set of labels
> 
> label_1:
>    somecode
> label_2:
>    somecode
> etcetera
> 
> I'm feeling pretty stupid having to ask, but how do I get the
> variable 'n' expanded in(to) the label?

It's a better question than it might seem at first! At one time, in some 
cases, Nasm would have done what you want. But it's been "tightened up" 
in recent versions, and you really need to use the "%+" operator!

label_%+n:

This generates "label_1:", "label_2:", etc. Nasm complains about 
"somecode" being redefined... so I replaced that with... well... "some 
code"... just "ret" to begin with. Same code in each "label" doesn't 
seem useful, but it worked... as long as we only do it once. But:

blop 3

blop 4

Now Nasm complains about "label_1" (etc.) being redfined! The solution 
to this is "macro-local" labels...

%%label_%+n:

Now Nasm generates (use the "-E" switch on the command line to see this):

..@0.label_1:
ret
..@0.label_2:
ret
..@0.label_3:
ret
..@1.label_1:
ret
...etc.

In order to get different code, I added "cmp eax, n" to the macro. I'm a 
little surprised that Nasm doesn't complain about "n" being redefined, 
but it still worked...

> Later I also want to generate:
> 
> global  label_n:func
> lenlab_n    db      *-label_n
> 
> (with 'n' being my variable).

I suspect you want '$', not '*'. The '$' is evaluated where it occurs, 
so this length calculation needs to be done right after the "label" 
code. This means that the "db" gets executed, which we surely don't 
want! I changed it to "equ", which may or may not suit your purposes. 
There may be a better workaround to this(?). I've come up with this, so far:


;-----------------------
    %macro blop 1
    %assign n 0

    %rep %1
    %assign n n+1

global %%label_%+n:func

%%label_%+n:
     cmp eax, n
     ret
%%label_%+n%+_len equ $ - %%label_%+n
    %endrep

    %endmacro

blop 3

blop 4

mov cl, ..@4.label_1_len
;---------------------------

This seems to "work"... Note that instead of "..@1", "..@2" as I would 
have expected, Nasm has jumped to "..@4" for the "macro-local labels" in 
the second invocation of the macro (dunno why). This makes it rather a 
PITA to use the length outside of the macro! I don't know if it's 
"useful" or not...

FWIW, I created this list at the request of another developer, to keep 
this kind of question off the "developer's list". It gets very little 
traffic. There's the "Nasm Forum" here:

http://forum.nasm.us

which is also suitable for this kind of question. You might get better 
results there.

Reminder to all subscribers: hit "reply all" to reply to this list - 
just "reply" goes only to the poster (me, in this case).

My apologies if you intended to "withdraw" the question. I thought it 
was worth trying to answer, even if SF denies that it exists. :)

Best,
Frank

Re: [Nasm-users] What debugger front end for Linux?

[Jakob B. <jb...@wi...>]

On 16-05-2011 17:34, Anonymous wrote:
>
> Thank you. I finally found a problem was reported on the insight front end
> to gdb back in 2009 causing a segfault, looks like it was never fixed. So I
> am using ddd for now, it's not as pretty as insight but it doesn't crash
> LOL. I finally found where to say Intel format instead of ATT so now I am
> doing better. I'm so happy about NASM, how can anybody stand to use ATT
> format or gas? It's a crime against humanity!
>
Note that recent versions of gas have started to support Intel syntax 
too.  That pseudo-Motorola syntax was
indeed an abomination.

Re: [Nasm-users] What debugger front end for Linux?

[Fritz W. <fr...@sp...>]

You wrote:

> Fritz Wuehler wrote:
> > Hi guys, I am trying to learn x86 assembly with NASM since it uses the less
> > hideous Intel syntax! However the debugger front end I tried doesn't seem to
> > recognize this format and I can't set breakpoints. Whoever is using NASM on
> > Linux can you explain your environment a bit, what tools should I be using
> > etc. for best results. Thanks guys.
> 
> There was recently some discussion of debuggers for Linux on the Nasm Forum:
> 
> http://forum.nasm.us/index.php?topic=1056.0

I'll have a look, thanks.

> 
> You don't say what debugger front end you tried, but ASSuming it's for 
> gdb...

Sorry about that! New as I am to Linux development I ASSumed there was only
gdb!

> 
> 1)It seems to help to start with a "nop" right after the "_start:" 
> label. If you're starting with "main", so that the "_start:" label is 
> elsewhere, this may not help.
> 
> 2)Give Nasm "-F dwarf" on the command line. The default is "stabs" if 
> you just use the "-g" switch. I honestly don't see any difference, but 
> "dwarf" is the "native" format, and is supposed to be "better".

I've been using stabs but as you and the previous poster said dwarf, I'll
start using that instead.

> 
> 3) Don't give ld the "-s" switch, of course, or it'll strip the debug 
> info back out. :)

Right :-)

> 
> 4) Nasm's "local label" syntax doesn't play nicely with gdb. You can use 
> local labels, but don't expect to tell gdb about 'em - it thinks you're 
> trying to reference  a member of a structure!

Good to know.

> 
> If none of that helps, tell us more about exactly what you're doing, and 
> what's happening.

Thank you.

Re: [Nasm-users] What debugger front end for Linux?

[Anonymous <cr...@ec...>]

You wrote:

> On 16-05-2011 12:57, Fritz Wuehler wrote:
> > Hi guys, I am trying to learn x86 assembly with NASM since it uses the less
> > hideous Intel syntax! However the debugger front end I tried doesn't seem to
> > recognize this format and I can't set breakpoints. Whoever is using NASM on
> > Linux can you explain your environment a bit, what tools should I be using
> > etc. for best results. Thanks guys.
> >
> I have not debugged nasm code on Linux, so I have no specific advice for 
> you, but here are some general
> info to help you along:
> 
> Hmm, maybe it is not the nasm format, but the debug information format 
> that is the problem.  As on all platforms, there are different file
> formats that compilers, assemblers etc. can use to tell debuggers which
> code bytes in the output file correspond to which lines in your source 
> code file and what the name of that file is.

Thank you. I finally found a problem was reported on the insight front end
to gdb back in 2009 causing a segfault, looks like it was never fixed. So I
am using ddd for now, it's not as pretty as insight but it doesn't crash
LOL. I finally found where to say Intel format instead of ATT so now I am
doing better. I'm so happy about NASM, how can anybody stand to use ATT
format or gas? It's a crime against humanity!

> In the case of Linux/Unix/GNU tools it may also be mandatory to include 
> NASM directives to mark the beginning and end of each named function, as
> gdb seems to be overly focused on checking that information before looking
> at anything real.

I will try and remember this. At the moment I'm writing just a few
instructions to try and learn and go through the book.

> Anyway, most current Linux tools use the GNU DWARF debug information 
> format, I don't know if NASM includes DWARF information in its elf32
> output files.

I was reading a book that said to use stabs debug info but I will try and
see if I can use dwarf and get better results. I am using elf64 format at
the moment.

Re: [Nasm-users] What debugger front end for Linux?

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

Fritz Wuehler wrote:
> Hi guys, I am trying to learn x86 assembly with NASM since it uses the less
> hideous Intel syntax! However the debugger front end I tried doesn't seem to
> recognize this format and I can't set breakpoints. Whoever is using NASM on
> Linux can you explain your environment a bit, what tools should I be using
> etc. for best results. Thanks guys.

There was recently some discussion of debuggers for Linux on the Nasm Forum:

http://forum.nasm.us/index.php?topic=1056.0

You don't say what debugger front end you tried, but ASSuming it's for 
gdb...

1)It seems to help to start with a "nop" right after the "_start:" 
label. If you're starting with "main", so that the "_start:" label is 
elsewhere, this may not help.

2)Give Nasm "-F dwarf" on the command line. The default is "stabs" if 
you just use the "-g" switch. I honestly don't see any difference, but 
"dwarf" is the "native" format, and is supposed to be "better".

3) Don't give ld the "-s" switch, of course, or it'll strip the debug 
info back out. :)

4) Nasm's "local label" syntax doesn't play nicely with gdb. You can use 
local labels, but don't expect to tell gdb about 'em - it thinks you're 
trying to reference  a member of a structure!

If none of that helps, tell us more about exactly what you're doing, and 
what's happening.

Best,
Frank

Re: [Nasm-users] What debugger front end for Linux?

[Jakob B. <jb...@wi...>]

On 16-05-2011 12:57, Fritz Wuehler wrote:
> Hi guys, I am trying to learn x86 assembly with NASM since it uses the less
> hideous Intel syntax! However the debugger front end I tried doesn't seem to
> recognize this format and I can't set breakpoints. Whoever is using NASM on
> Linux can you explain your environment a bit, what tools should I be using
> etc. for best results. Thanks guys.
>
I have not debugged nasm code on Linux, so I have no specific advice for 
you, but here are some general
info to help you along:

Hmm, maybe it is not the nasm format, but the debug information format 
that is the problem.  As on all
platforms, there are different file formats that compilers, assemblers 
etc. can use to tell debuggers which
code bytes in the output file correspond to which lines in your source 
code file and what the name of
that file is.

In the case of Linux/Unix/GNU tools it may also be mandatory to include 
NASM directives to mark the
beginning and end of each named function, as gdb seems to be overly 
focused on checking that
information before looking at anything real.

Anyway, most current Linux tools use the GNU DWARF debug information 
format, I don't know if NASM
includes DWARF information in its elf32 output files.

[Nasm-users] What debugger front end for Linux?

[Fritz W. <fr...@sp...>]

Hi guys, I am trying to learn x86 assembly with NASM since it uses the less
hideous Intel syntax! However the debugger front end I tried doesn't seem to
recognize this format and I can't set breakpoints. Whoever is using NASM on
Linux can you explain your environment a bit, what tools should I be using
etc. for best results. Thanks guys.

Re: [Nasm-users] please help

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

kevin becker wrote:
> ok thank you  :)
> 
> im trying to learn ASM so i can make an OS, im working on logo

You might find some of the information on this site useful:

http://wiki.osdev.org/Main_Page

Good luck!

Best,
Frank

Re: [Nasm-users] please help

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

kevin becker wrote:
> uhm ok iguess.
> ive heard of something called virtual computer which i guess simulates 
> what happens if you run things/do things on your comp, but since its a 
> simulation there's no danger of screwing up files.

Mmmm, no chance of altering files legitimately either, then?

> if i download Mac on it, would Nasm work normally??

Dunno. It "should", if the emulation is correct, I guess. Try it. Seems 
like it might be the hard way... Try it... no harm done(?) if it doesn't 
work normally...

Best,
Frank




> 
> ss simOn Tue, Mar 8, 2011 at 1:13 PM, Frank Kotler <fbk...@zy... 
> <mailto:fbk...@zy...>> wrote:
> 
>     kevin becker wrote:
> 
>         uhm
> 
>         when i click on the NASM.exe, it pops upon, and then closes
>         before anything can be even SEEN
> 
>         it doesn't do anything....
> 
> 
>     Ah, okay. Nasm is a "command line" utility. That is, at a "command
>     prompt", you'd type "nasm -f win32 -i c:\my\includes\ -o myfile.obj
>     myfile.asm", or so. You can get a command prompt by doing
>     start->run->"cmd" - I think that still works. Alternatively, there's
>     a way to make a "shortcut" to Nasm that will pop up a dialog-box
>     when you click on it that will allow you to enter a command line.
>     I'm afraid I don't remember how that one goes -
>     "properties->advanced" somewhere, no doubt...
> 
>     Or, you might prefer an "IDE" - an "Integrated Development
>     Environment" which will allow you to clickie-clickie to edit,
>     assemble, run, debug, etc. NaGoA was one created for Nasm. It
>     appears to be "abandoned", but still works, AFAIK.
> 
>     http://www.visual-assembler.pt.vu/
> 
>     (wow! that's *really* looking abandoned!)
> 
>     Probably the most popular IDE is RadAsm...
> 
>     http://radasm.cherrytree.at/radasm/
> 
>     You can use Nasm with Visual Studio, too, I understand, though it
>     may take more "setup" than with RadAsm(?). I prefer working from a
>     command prompt, myself, and I'm not running Windows, so I can't help
>     you much. Maybe someone who is can give you more specific advice...
>     What you're seeing is "normal behavior" from Nasm. The error
>     message, which goes by too fast to see, says "error: no input file
>     specified".
> 
>     Best,
>     Frank
> 
> 
> 
> 
> -- 
> (>^_^)># I made you a waffle
> #<(^_^<) But then I was like...
> (>^#^<) "I'm hungry..."
> (>^_^)> So I ate it.
>  
> 

Re: [Nasm-users] please help

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

Frank Kotler wrote:
> (Incidentally, click "reply all" to reply to the list - otherwise it 
> goes just to me.

Jeez, I did it myself...

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

kevin becker wrote:
 > uhm
 >
 > when i click on the NASM.exe, it pops upon, and then closes before 
anything can be even SEEN
 >
 > it doesn't do anything....

Ah, okay. Nasm is a "command line" utility. That is, at a "command 
prompt", you'd type "nasm -f win32 -i c:\my\includes\ -o myfile.obj 
myfile.asm", or so. You can get a command prompt by doing 
start->run->"cmd" - I think that still works. Alternatively, there's a 
way to make a "shortcut" to Nasm that will pop up a dialog-box when you 
click on it that will allow you to enter a command line. I'm afraid I 
don't remember how that one goes - "properties->advanced" somewhere, no 
doubt...

Or, you might prefer an "IDE" - an "Integrated Development Environment" 
which will allow you to clickie-clickie to edit, assemble, run, debug, 
etc. NaGoA was one created for Nasm. It appears to be "abandoned", but 
still works, AFAIK.

http://www.visual-assembler.pt.vu/

(wow! that's *really* looking abandoned!)

Probably the most popular IDE is RadAsm...

http://radasm.cherrytree.at/radasm/

You can use Nasm with Visual Studio, too, I understand, though it may 
take more "setup" than with RadAsm(?). I prefer working from a command 
prompt, myself, and I'm not running Windows, so I can't help you much. 
Maybe someone who is can give you more specific advice... What you're 
seeing is "normal behavior" from Nasm. The error message, which goes by 
too fast to see, says "error: no input file specified".

Best,
Frank

Re: [Nasm-users] please help

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

kevin becker wrote:
> 
> i have ap orblem whenever i try to run it it shuts down instantly. It 
> does the same thing when i run a program in Dev C++, but that i can just 
> type system("PAUSE);
> please help me
> thanx
> -- 
> (>^_^)># I made you a waffle
> #<(^_^<) But then I was like...
> (>^#^<) "I'm hungry..."
> (>^_^)> So I ate it.

FUNEM?
SIFM.
FUNEX?
SIFX.
OKMNX.
(since you've eaten all the waffles...) :)

Hi Kevin,

I'm not quite clear what "it" is. (like Bill Clinton :) )

Is Nasm quitting on you before it assembles your file? Or is your 
program exiting before you can see the result? The mention of 
"system("pause"); sounds like the latter(?). We can call system() from 
assembly, too, of course. Probably you want to wait for a keystroke(?). 
How you do that depends on your OS, or if you're linking against a C 
library, getc()...

I think we need more information about exactly what you did, and what 
happened (as opposed to what you wanted to happen).

Best,
Frank

(Incidentally, click "reply all" to reply to the list - otherwise it 
goes just to me. I've cleared your "moderation flag", so your message 
ought to appear right away, this time. Sorry for the delay.)

[Nasm-users] please help

[kevin b. <maj...@gm...>]

i have ap orblem whenever i try to run it it shuts down instantly. It does
the same thing when i run a program in Dev C++, but that i can just type
system("PAUSE);
please help me
thanx
-- 
(>^_^)># I made you a waffle
#<(^_^<) But then I was like...
(>^#^<) "I'm hungry..."
(>^_^)> So I ate it.

Re: [Nasm-users] Working with pointers

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

Littlefield, Tyler wrote:
> Rather than filling everyone's inbox replying to all of these, just 
> wanted to say thanks for all the help.

Hi Tyler,

You're welcome. I'm going to undo your consideration and fill up 
everybody's mailbox, though, 'cause I think your questions are 
interesting, and might lead to some discussion. If anyone thinks this 
list is generating too much traffic, they can complain... or just 
unsubscribe. :)

> It helped. I have two more 
> questions. First, I'm working with Unix systems. How would I go about 
> creating a socket, closing the socket, etc?

ASSuming you want to do this via the int 80h interface, there's really 
only one sys_socketcall (102). This is usually "wrapped" to socket 
(create), connect, bind, listen, etc. Even Konstantin's "asmutils" 
provides macros for sys_socket, etc. But the "real" interface is just 
sys_socketcall, with the subfunctions or "commands" in ebx - ecx points 
to remaining parameters. In order to not "hide" anything, I like to do 
it that way, although we're "supposed" to use the C library interface 
(they make me say that). There are "send" and "recv" commands, but 
sys_write/sys_read seem to work - sys_close seems to work - just like 
any other file descriptor.

> Last, do we have some sort 
> of method for using malloc? I don't think it's an actual syscall, but I 
> need to be able to allocate memory.

Well, "just call malloc". There are a couple of system calls that will 
get us a chunk of memory - sys_mmap (or mmap2?) and sys_brk. These get 
us a minimum of 4096 bytes. To "malloc" smaller pieces, we're on our 
own. I think Jonathan Bartlett's "PGU" has an example. I think sys_mmap 
gets us memory starting about 40000000h, sys_brk gives us memory 
contiguous with the end of our existing memory, which may be an 
advantage(?). As I recall, "man 2 brk" isn't too helpful (unusually).

xor ebx, ebx
mov eax, 45
int 80h
; check for error - shouldn't be any(?)
mov [orig_break], eax
mov ebx, eax
add ebx, 4096 ; or some multiple
mov eax, 45
int 80h
; check for error - might be out of memory

Now eax should have our new "break" (where memory ends for our process). 
We can use memory between "orig_break" and "new_break". To "free" it:

mov ebx, [orig_break]
mov eax, 45
int 80h

Now we should be back where we were. I think that works...

Getting back to sockets, here's my adaptation of Scott Lanning's 
"daytime_cli.s" (available at Konstantin's linuxassembly.org, or 
http://asm.sf.net somewhere):

;-----------------------------
; daytime client in Linux asm, syscalls only
; loosely based on daytime_cli.s from Scott Lanning
;
; nasm -f elf32 daytime.asm
; ld -o daytime daytime.o

global _start

struc sockaddr_in
     .sin_family resw 1
     .sin_port resw 1
     .sin_addr resd 1
     .sin_zero resb 8
endstruc

_ip equ 0x7F000001		; loopback - 127.0.0.1
_port equ 13

; Convert numbers to network byte order

IP equ ((_ip & 0xFF000000) >> 24) | ((_ip & 0x00FF0000) >>  8) | ((_ip & 
0x0000FF00) <<  8) | ((_ip & 0x000000FF) << 24)
PORT equ ((_port >> 8) & 0xFF) | ((_port & 0xFF) << 8)

AF_INET        equ 2
SOCK_STREAM    equ 1

BUFLEN         equ  0x80


STDIN          equ 0
STDOUT         equ 1

__NR_exit	equ 1
__NR_read       equ 3
__NR_write      equ 4
__NR_socketcall equ 102

SYS_SOCKET     equ 1
SYS_CONNECT    equ 3

section .data

my_sa istruc sockaddr_in
     at sockaddr_in.sin_family, dw AF_INET
     at sockaddr_in.sin_port, dw PORT
     at sockaddr_in.sin_addr, dd IP
     at sockaddr_in.sin_zero, dd 0, 0
iend

socket_args dd AF_INET, SOCK_STREAM, 0

; first of these wants to be socket descriptor
; we fill it in later...
connect_args dd 0, my_sa, sockaddr_in_size


section .bss
     my_buf resb BUFLEN
     sock_desc resd 1


section .text
  _start:

     ; socket(AF_INET, SOCK_STREAM, 0)

     mov     ecx, socket_args	; address of args structure
     mov     ebx, SYS_SOCKET     ; subfunction or "command"
     mov     eax, __NR_socketcall     ;c.f. /usr/src/linux/net/socket.c
     int     80h

     cmp     eax, -4096
     ja      exit

     mov     [sock_desc], eax
     ; and fill in connect_args
     mov	    [connect_args], eax

      ; connect(sock, (struct sockaddr *)&sa, sizeof(struct sockaddr))

     mov     ecx, connect_args
     mov     ebx, SYS_CONNECT	; subfunction or "command"
     mov     eax, __NR_socketcall
     int     80h

     cmp     eax, -4096
     ja      exit

     ; read(sock, buf, len)
     mov     edx, BUFLEN		; arg 3: max count
     mov     ecx, my_buf		; arg 2: buffer
     mov     ebx, [sock_desc]	; arg 1: fd
     mov     eax, __NR_read	; sys_read
     int     80h

     cmp     eax, -4096
     ja      exit

     ; write(stdout, buf, len)
     mov     edx, eax		; length read is length to write
     mov     ecx, my_buf
     mov     ebx, STDOUT
     mov     eax, __NR_write
     int     80h

     xor eax, eax		; success
  exit:
     mov     ebx, eax		; exitcode
     mov     eax, __NR_exit
     int     80h
;----------------------

That probably won't do anything, unless you've already got a "daytime" 
server running. Edit (as root) /etc/inetd.conf and uncomment the 
"daytime" line. Do "ps x" to get the ID for inetd, and "kill -HUP xxxx". 
Works for me. If your system is different, enlighten me!

I have a couple other examples... an "echo" (or echo-like) client and 
server (not a very good "server"). I also have a couple examples Nathan 
Baker sent me - Windows programs using the NASMX package. I've written a 
"fakeapi.asm" containing functions with the same names and parameters as 
the Windows APIs, that do "approximately" the same thing. Linking 
(statically) against this allows the same programs to run in Linux. This 
is just a novelty, and will *not* work in the "general case", but I 
thought it was amusing...

If anyone wants to see any of these, give a yell.

Best,
Frank

Re: [Nasm-users] Working with pointers

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

Shucks! I replied to this, but forgot: you've gotta click on "reply 
all", just "reply" goes just to the sender! Didn't mean to send it to 
just you, Jakob. Sorry 'bout that.


Jakob Bohm wrote:
> On 17-12-2010 07:27, Littlefield, Tyler wrote:
>> hello all,

Hi Tyler, Hi Jakob,

>> I have a quick question.
>> I have the following:
>> section .data
>> ptr dd 0
>> array times 100 db 0
>>
>> Now, when I want to assign array to p,

What's "p"?

>> I can't mov it--how can I assign
>> the pointer to point there? Last, is there a way to get the type of
>> processor?
>> (32-64), as that will make a difference on the code in some places?
>>
> 
> ; For 32 bits, I think this should assemble just fine:
> 
>      ptr dd 0
>      array times 100 db 0
> 
>      mov [ptr], array

I think Nasm's going to whine "operation size not specified" unless we
tell it:

mov dword [ptr], array

> ; For 64 bits, The code should become
> 
>      ptr dq 0
>      array times 100 db 0
> 
>      lea rax,[array] ; Add some notation here to make this rip relative!
>      mov [ptr], rax
> 
> I don't know how to test if nasm is compiling for 16, 32 or 64 bits with 
> assembler directives,

Nasm knows both "__BITS__" and "__OUTPUT_FORMAT__", whichever is most
useful... To find what CPU, "cpuid"? It is also possible to write code
that will distinguish at runtime what mode the CPU is actually in, using
the fact that "dec"->"REX prefix". See news:comp.lang.asm.x86 "Standard
idiom for prologue to ambivalent code" for details.

> sorry I don't do that much nasm coding these days.

Well, *that's* easy to fix! :)

Best,
Frank

Re: [Nasm-users] Working with pointers

[<p1...@ja...>]

On 12/17/2010 4:37 AM, Jakob Bohm wrote:
> On 17-12-2010 07:27, Littlefield, Tyler wrote:
>> hello all,
>> I have a quick question.
>> I have the following:
>> section .data
>> ptr dd 0
>> array times 100 db 0
>>
>> Now, when I want to assign array to p, I can't mov it--how can I assign
>> the pointer to point there? Last, is there a way to get the type of
>> processor?
>> (32-64), as that will make a difference on the code in some places?
>>
> ; For 32 bits, I think this should assemble just fine:
>
>       ptr dd 0
>       array times 100 db 0
>
>       mov [ptr], array
>
> ; For 64 bits, The code should become
>
>       ptr dq 0
>       array times 100 db 0
>
>       lea rax,[array] ; Add some notation here to make this rip relative!
>       mov [ptr], rax
>
> I don't know how to test if nasm is compiling for 16, 32 or 64 bits with
> assembler directives,
> sorry I don't do that much nasm coding these days.
>

Here is one way:

%ifidn __BITS__,64
     ptr dq 0
%else
     ptr dd 0
%endif

Re: [Nasm-users] Working with pointers

[Jakob B. <jb...@wi...>]

On 17-12-2010 07:27, Littlefield, Tyler wrote:
> hello all,
> I have a quick question.
> I have the following:
> section .data
> ptr dd 0
> array times 100 db 0
>
> Now, when I want to assign array to p, I can't mov it--how can I assign
> the pointer to point there? Last, is there a way to get the type of
> processor?
> (32-64), as that will make a difference on the code in some places?
>

; For 32 bits, I think this should assemble just fine:

     ptr dd 0
     array times 100 db 0

     mov [ptr], array

; For 64 bits, The code should become

     ptr dq 0
     array times 100 db 0

     lea rax,[array] ; Add some notation here to make this rip relative!
     mov [ptr], rax

I don't know how to test if nasm is compiling for 16, 32 or 64 bits with 
assembler directives,
sorry I don't do that much nasm coding these days.