nasm-users — Discussion and help for Nasm users.

[Nasm-users] Issue compiling gens with nasm 0.99.01 and cvs version

[Guillaume B. <lit...@za...>]

Hello,

I'm trying to compile a game console emulator named gens, running Linux
on an athlon-xp.

The compilation fails with lots of these messages :

nasm -O1 -D__GCC2 -felf -I./gens_core/ -I./gens_core/io/
-I./gens_core/misc/ -I./gens_core/vdp/ -I./gens_core/sound/
-I./gens_core/gfx/ -I./gens_core/cpu/sh2/ -I./gens_core/cpu/z80/
-I./gens_core/mem/ gens_core/gfx/blit.asm -o gens_core/gfx/blit.o
gens_core/gfx/blit.asm:181: error: invalid operands in non-64-bit mode
[...]
gens_core/gfx/blit.asm:2034: error: invalid operands in non-64-bit mode
gens_core/gfx/blit.asm:2035: error: invalid operands in non-64-bit mode
make[3]: *** [gens_core/gfx/blit.o] Erreur 1

If I understood correctly, the code uses MMX instructions.
I've seen some recent additions on the CVS concerning this, so i've
tried again with the very latest nasm, but with no help.

It compiles fine with 0.98.39 (of course).

How can I help fixing this ?

Best regards,

Guillaume Bedot.


PS: As the blit.asm file seems too big for the list, please go to
http://sourceforge.net/project/showfiles.php?group_id=73619 to download
gens source.

[Nasm-users] Issue compiling gens with nasm 0.99.01 and cvs version

[Guillaume B. <lit...@za...>]

Hello,

I'm trying to compile a game console emulator named gens, running Linux
on an athlon-xp.

The compilation fails with lots of these messages :

nasm -O1 -D__GCC2 -felf -I./gens_core/ -I./gens_core/io/
-I./gens_core/misc/ -I./gens_core/vdp/ -I./gens_core/sound/
-I./gens_core/gfx/ -I./gens_core/cpu/sh2/ -I./gens_core/cpu/z80/
-I./gens_core/mem/ gens_core/gfx/blit.asm -o gens_core/gfx/blit.o
gens_core/gfx/blit.asm:181: error: invalid operands in non-64-bit mode
[...]
gens_core/gfx/blit.asm:2034: error: invalid operands in non-64-bit mode
gens_core/gfx/blit.asm:2035: error: invalid operands in non-64-bit mode
make[3]: *** [gens_core/gfx/blit.o] Erreur 1

If I understood correctly, the code uses MMX instructions.
I've seen some recent additions on the CVS concerning this, so i've
tried again with the very latest nasm, but with no help.

It compiles fine with 0.98.39 (of course).

How can I help fixing this ?

Best regards,

Guillaume Bedot.

[Nasm-users] Very hot peport.

[Tripp J. <Tri...@PR...>]

Important symbol
http://img129.imageshack.us/my.php?image=8qdexk46mb9.gif
Because the idea of an "end" is intolerable to me.

Re: [Nasm-users] nasm: unrecognised output format "macho" - need help

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

Some time ago...

Frank wrote:
> Hi Frank,
> 
> thank you for your fast answer !

Well, BLEEP!!! I'm *trying* to get you a fast answer again, but the
universe isn't cooperating! Yesterday the power kept blippin' out before
I could finish. About midnight, the internet became the internot.
Apparently Verizon's local office is underwater. I understand the
news-weasels say it may be out for a week. Unacceptable! Well, I can
write, anyway, and send it when "they get it fixed". So okay, I just
wrote up some Nasm features, some undocumented, that might be
relevant... "just wrap it up and save it"... when Blam! Power out again.
I'm gettin' really annoyed. I may just send this as-is, when I'm able.
BLEEP!!!

-------------------
"present day", as they say in the movies...

Well, the internot has turned back into the internet. Whew!!!

I haven't the ambition to finish this up properly, ATM. I've looked a 
little at the "macho" source code... I conclude that macho *does* want 
underscores, so you *don't* want to define "ELF_TYPE"...

I hope you've sorted this out by now. If not, holler again! Mostly, I 
want to throw this question back at "the list". I was disappointed to 
see that no one else answered... but then remembered...
-------------------
(over a week ago)

>> Hi Frank!

Hint to all subscribers: I personally consider it to be a PITA, but the
docs strongly encourage us to configure the lists this way: In order to
reply to the list (and the poster), you have to hit "reply all. Just
"reply" replies *only* to the poster.

Assuming you intended to reply to the list, I'll add 'em back in. (Hi List!)

>>> I installed nasm 0.38.39 on MacOS X. But it seems that nasm does not  
>>> know the file output format "macho" (Mac OS binary). I am receiving  
>>> the error "nasm: fatal: unrecognised output format `macho'"
>>
>>
>> Macho was added in 0.38.40 - not available as a "release" on 
>> SourceForge. You can get it from Apple:
>>
>> http://www.opensource.apple.com/darwinsource/10.4.5.x86/
> 
>> as "nasm-2" (scroll way down). Nasm on SF is "undergoing alterations". 
>> We expect a release of 0.99(!) with not only Macho but 64-bit 
>> support(!)... "real soon now".
> 
> 
>  >>Correction!!! Apple's latest 0.98.40 is *here*:
>  >>http://www.opensource.apple.com/darwinsource/10.4.8.x86/ as 
> "nasm-11"! There *are* differences... dunno how significant.
> 
> The nasm source can be compiled without problems. After a while I found 
> out that the newest version of nasm is like gcc alreeady included in the 
> XCode 2.4.1_8 pack (Apple developement package).

Ah ha! Good! I was looking at the differences in the "Apple version".
They "make" the docs slightly differently, and "make install" things in
slightly different places. Not *much* difference, but if they provide a
reasonably new version, their "distro" will be the one you want, probably.

> In the past I installed 
> the latest offical nasm release which was overwriting the version 
> inclueded in XCode. (stupid mistake)

Generally, I'd advise "the latest official version from SourceForge",
but on a Mac, "from Apple" is probably better. If they should ever "fall
behind", we can look into an "Apple version on SF"...

Right now, Nasm is in transition to 64-bit code, and you might not
*want* the very latest version! :)

> I also can compile the latest apple version, or install the latest XCode 
> release.

Okay!

>>> I would be please if you could tell what my mistake has been.
>>
>> No mistake... unless expecting Nasm to be ready for ya. You'll have to 
>> grab a "preview" version - from Apple, or off the CVS tree (anonymous 
>> CVS is *not* synched with developer CVS so you might miss the very 
>> latest changes...), and compile it yourself.
>>
>> If you do so, and get it working, I'd like to see a simple 
>> example"hello world". Low-level as MacOS will allow - I assume "call 
>> printf" looks like "call printf"... but it might be "call _printf", 
>> even that information would be interesting!
> 
> 
> It almost work for me, here my results:
> 
> asm files can be compiled into the macho format without any problems.
> BUT an additional underline has to be used when linking with gcc. 
> (FreeBSD seems to use additional underlines, as far as I know MacOS is 
> based on FreeBSD so I am forced to use underlines here, too.)
> I am using a small C application to run the asm file. The gcc compiles 
> this c file without problems, too.
> 
> So I picked a "Hello World" source from Wikipedia in Assembler for 
> FreeBSD, x86 Intel based (MacBooks for example, Intel CPU), compiled and 
> linked all objects files with success.
> 
> I tooked a screenshot of the Terminal's output: 
> http://home.arcor.de/frank-u/hw.png

Looks good!

> Here is the "Hello World" code (for FreeBSD, Intel x86):
> _______________________________
> section .data
>    hello_world db 'Hi Frank !', 0x0a
>    hello_world_len equ $ - hello_world
>  section .text
>    align 4

Nasm's "-f elf" output format aligns section .text on 16 bytes anyway,
so this doesn't do anything. No harm. If you really wanted to cut the
alignment down to 4, "section .text align=4"... but you don't.

>    sys:
>      int 0x80
>      ret
>    global _start
>    _start:
>      push hello_world_len
>      push hello_world
>      push 1
>      mov eax, 4
>      call sys
>      push 0
>      mov eax, 1
>      call sys
> ____________________________________
> 
> My C file:
> ____________________________________
> #include "cdecl.h" 
> int PRE_CDECL start( void ) POST_CDECL; 

I have no idea what this does. Normally, the "_start" label, which ld
knows as the default entrypoint, would be in the C startup code,
"crt0.o". An assembly program that's just a "module" wouldn't have the
"_start" label, but "global my_asm_function". Apparently, what you've
done here allows your module to be run *either* freestanding or callable
from C. Neat trick!

To link it as "freestanding", "ld -o hw hw.o". (I imagine that'll work
with Mac...)

> int main() 
> { 
>   int ret_status; 
>  ret_status = start(); 

In this case, we don't return...

>   return ret_status; 
> }
> ____________________________________
> 
> 
> But in the following situation I can not link with gcc at all:
> 
> We are learning Assembler by using the Tutorial from Dr. Paul Carter.
> He offers macros in a asm file called "asm_io.asm" which we "must" use. 
> (Included in his package: http://www.drpaulcarter.com/pcasm/linux-ex.zip)
> 
> The last step is to link those object files with gcc which cause an 
> error with asm_io.o:

What about the next-to-last step? "asm_io.asm" expects "-d ELF_TYPE" on
Nasm's command line. This strips the underscores from "_main",
"_printf", etc. If you didn't do that, try it. If you did, try it
without. If neither of those options work... we may need to add a
"BSD_TYPE" and/or "MAC_TYPE" to "asm_io.asm".

> Output file: example, My C file: ctest.o, My Assembler file: asmtest.o, 
> Macro file: asm_io.o
> gcc -o example ctest.o asmtest.asm asm_io.o
> 
> The compiler throws the following error:
> ___________________________
> /usr/bin/ld: asm_io.o has external relocation entries in non-writable 
> section (__TEXT,__text) for symbols:
> _printf
> _putchar
> _getchar
> _scanf
> collect2: ld returned 1 exit status
> __________________________
> 
> May you have any idea what I am doing wrongly or if I can even use this 
> macro file. (The linking process only works if I do not use the macro 
> and its functions).
> 
> Thanks,
> Frank
> 

Re: [Nasm-users] nasm: unrecognised output format "macho" - need help

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

Frank Kotler wrote:

...
> Macho was added in 0.98.40 - not available as a "release" on 
> SourceForge. You can get it from Apple:
> 
> http://www.opensource.apple.com/darwinsource/10.4.5.x86/
> 
> as "nasm-2" (scroll way down).

Correction!!! Apple's latest 0.98.40 is *here*:

http://www.opensource.apple.com/darwinsource/10.4.8.x86/

as "nasm-11"! There *are* differences... dunno how significant.

Best,
Frank

Re: [Nasm-users] nasm: unrecognised output format "macho" - need help

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

Hi Frank!

> I installed nasm 0.38.39 on MacOS X. But it seems that nasm does not  
> know the file output format "macho" (Mac OS binary). I am receiving  
> the error "nasm: fatal: unrecognised output format `macho'"

Macho was added in 0.38.40 - not available as a "release" on 
SourceForge. You can get it from Apple:

http://www.opensource.apple.com/darwinsource/10.4.5.x86/

as "nasm-2" (scroll way down). Nasm on SF is "undergoing alterations". 
We expect a release of 0.99(!) with not only Macho but 64-bit 
support(!)... "real soon now".

> But in the nasm documentation the parameter "macho" is listed.

You must be looking at newer-than-0.98.39 docs. The "-hf" switch should 
give you a list of the output formats in that particular executable. 
*Should* be accurate.

> I would be please if you could tell what my mistake has been.

No mistake... unless expecting Nasm to be ready for ya. You'll have to 
grab a "preview" version - from Apple, or off the CVS tree (anonymous 
CVS is *not* synched with developer CVS so you might miss the very 
latest changes...), and compile it yourself.

If you do so, and get it working, I'd like to see a simple example"hello 
world". Low-level as MacOS will allow - I assume "call printf" looks 
like "call printf"... but it might be "call _printf", even that 
information would be interesting!

Best,
Frank

[Nasm-users] nasm: unrecognised output format "macho" - need help

[Frank <fr...@ar...>]

Hi,

I installed nasm 0.38.39 on MacOS X. But it seems that nasm does not  
know the file output format "macho" (Mac OS binary). I am receiving  
the error "nasm: fatal: unrecognised output format `macho'"

But in the nasm documentation the parameter "macho" is listed.

I would be please if you could tell what my mistake has been.

Thanks !
Frank

Re: [Nasm-users] Hello NASM

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

Oops! Almost didn't cc this to the list! To reply to this list, hit
"reply all" - "reply" just replies to the sender! (PITA, but SF strongly
recommends it be set up that way)


xbw...@si... wrote:
> Hi, All
> 
> I am asm beginner. Hope I can get help here.

Hi Boris,

Some people will tell you that folks who are into asm are "beyond help".
Maybe we can prove 'em wrong...

Always exit cleanly. No matter what OS, the first thing we need to learn
(even if it's the last thing we do) is how to exit cleanly back to the OS.

Beyond that, we'll need to know what you need help with. :)

Best,
Frank

[Nasm-users] Hello NASM

[<xbw...@si...>]

SGksIEFsbA0gDUkgYW0gYXNtIGJlZ2lubmVyLiBIb3BlIEkgY2FuIGdldCBoZWxwIGhlcmUuIA0g
DVRoYW5rcywNQm9yaXMKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KtPPQobWly6sgu/q74bbgtuCjrDEwt9bW077Nv6q9
saOswaK8tLe1vbEoIGh0dHA6Ly9hZDQuc2luYS5jb20uY24vc2luYS9saW1lbmczL21haWxfemh1
aXl1LzIwMDcvbWFpbF96aHVpeXVfMjAwNzAzMTkuaHRtbCApCgo9PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CteisuHQwsDL
MkfD4rfR08rP5KOoIGh0dHA6Ly9tYWlsLnNpbmEuY29tLmNuL2Nob29zZU1vZGUuaHRtbCCjqQ==

[Nasm-users] contact your agent

[lottery w. <eur...@ya...>]

EUROMILLONES LOTERIAS Y APUESTAS DEL ESTADO
CALLE AROYO NO=2E 13 PISO 4G
28030 MADRID ESPANA
FROM=3A THE DESK OF THE VICE PRESIDENT=2E
INTERNATIONAL PROMOTIONS=2FPRIZE AWARD=2E
BATCH=3A EGS=2F22504002=2F03 =2C REFERENCE=3A15=2F0018=2FIPD
DATE=3A3RD MARCH 2007
ATTENTION=3A
RE=3AAWARD NOTIFICATION=2E
This is to inform you of the release of the EUROMILLONES LOTTERY
PRIMITIVA held on the 6th febuary 2007 Due to the mix up of numbers=2C
address and the holidays=2C the results were released on the 2nd march 2007
Your name attached to ticket number=2C 50745-0 with serial number
168-07632472-034 drew the lucky numbers of 03 04 27 29 37 which
consequently won the lottery in the 5th category=2E
You have therefore been approved for a lump sum payout of Euros
431=2C942=2E20c=29=28FOUR HUNDREH AND THIRTY ONE THOUSANDS=2CNINE HUNDREH FORTY
TWO EUROS AND TWENTY CENT=29in cash credited to file with REF=2E
NO=2EEGS=2F3662367114=2F13=2E This is from a total cash prize of Euros
18=2C693=2C642=2C00=29
Shared among the twenty three international winners in this category=2E
CONGRATULATIONS!!!
Your fund is now deposited with our Security Company and insured in
your name=2EDue to mix up of some numbers and names=2C we ask that you keep
this award from public notice until your claim has been processed and
money remitted to your account as this is part of our security protocol
to avoid double claiming or unwarranted taking advantage of this
program by participants as it has happened in the past=2E
All participants were selected through a computer ballot system drawn
from =28six million=29 names from Asia=2C Australia=2C New Zealand=2C Europe=2C
North and South America=2C Middle East and Africa as part of our
International
promotion program=2E We hope your lucky name will draw a bigger cash
prize in the subsequent programs=2E
To begin your lottery clai m=2C please contact your claiming
agent=2CMr=2EJOSE MIGUEL=2CForeign operation manager EUROMILLONES LOTTERY=2F
LA PRIMITIVA LOTTERY on Tel=3A+34-653-136-676=2CFax=3A+34-651-389-558 or via
email=3Aecobureau=40consultant=2Ecom
for the processing and remittance of your winning prize money to a
designation of your choice=2E
Remember=2Call prize money must be claimed not later than 30th march 2007=2E
Any claim not made before this date will be returned to the
MINISTERIO DE ECONOMIA Y HACIENDA=2EAnd also be informed that 10% of
your Lottery Winning belongs to =28IBERO PROMOTION COMPANY=29=2EBecause they
are the promotion company that bought your ticket and played the
lottery on your name=2Cthis ten percent will be remitted after you have
received your winnings because the money is insured in your name 
already=2E
NOTE=3A In order to avoid unnecessary delays and complications=2Cplease
remember to quote your reference and batch numbers in every
correspondence with us or your agent=2EFurthermore=2Cshould there be any
change of address=2Cdo
inform your claims agent as soon as possible=2EAn original copy of your
prize Winning Certificate will be sent to you after you have claimed
your winning=2ECongratulations once again from all members of our staff
and thank you for being part of our International promotion programs=2E
We wish you continued good fortunes=2E
Sincerely=2C
Mr=2E ANTHONIO GOMEZ=2C
VICE PRESIDENT

Re: [Nasm-users] pb with preprocessor Loop

[Gregory 'G. C. <ga...@cl...>]

Well, that's perfect !!!! Thank you VERY much.

I don't care the way it's done, only the result matters  :)

It's great to have people answering that fast, thanks again.

Greg

On Fri, 23 Feb 2007 12:15:48 -0500
Frank Kotler <fbk...@ve...> wrote:

> Gregory 'GaLi' Cavelier wrote:
> > Hello,
> > 
> > I've got the following code :
> [snip]
> 
> Since Nasm's local labels don't work quite the same as Gas', I had to 
> break it into two parts - a macro, so I could use a "macro-local label", 
> and the "%rep" loop calling the macro. I think this does what you want, 
> although it may not be the way you want to do it...
> 
> Best,
> Frank
> 
> %macro irq_entry 1
>      align 4
> 
> %%lbl:
>      mov  eax , esp
>      mov  edx , %1
>      SECTION .data
>      dd %%lbl
>      SECTION .text
> %endm
> 
> 
> SECTION .data
> interrupt:
> 
> SECTION .text
> 
> irq_entries_start:
> 
> %assign irq_nb 0
> %rep    4
> 
>      irq_entry irq_nb
> 
> %assign irq_nb irq_nb+1
> %endrep

-- 
                       _
ASCII ribbon campaign ( )
 - against HTML email  X
             & vCards / \

Re: [Nasm-users] pb with preprocessor Loop

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

Gregory 'GaLi' Cavelier wrote:
> Hello,
> 
> I've got the following code :
[snip]

Since Nasm's local labels don't work quite the same as Gas', I had to 
break it into two parts - a macro, so I could use a "macro-local label", 
and the "%rep" loop calling the macro. I think this does what you want, 
although it may not be the way you want to do it...

Best,
Frank

%macro irq_entry 1
     align 4

%%lbl:
     mov  eax , esp
     mov  edx , %1
     SECTION .data
     dd %%lbl
     SECTION .text
%endm


SECTION .data
interrupt:

SECTION .text

irq_entries_start:

%assign irq_nb 0
%rep    4

     irq_entry irq_nb

%assign irq_nb irq_nb+1
%endrep

[Nasm-users] pb with preprocessor Loop

[Gregory 'G. C. <ga...@cl...>]

Hello,

I've got the following code :


SECTION .data
interrupt:

SECTION .text

irq_entries_start:

%assign irq_nb 0
%rep    4

	ALIGN 4

	mov  eax , esp
	mov  edx , irq_nb

	SECTION .data
	dd $
	SECTION .text

%assign irq_nb irq_nb+1 
%endrep



I compile it with : nasm test1.s -o test1.o -f elf

Then, if I dump it with : objdump --disassemble-all test1.o |less

I get this :

test1.o:     file format elf32-i386

Disassembly of section .data:

00000000 <interrupt>:
   0:   00 00                   add    %al,(%eax)
   2:   00 00                   add    %al,(%eax)
   4:   04 00                   add    $0x0,%al
   6:   00 00                   add    %al,(%eax)
   8:   08 00                   or     %al,(%eax)
   a:   00 00                   add    %al,(%eax)
   c:   0c 00                   or     $0x0,%al
        ...
Disassembly of section .text:

00000000 <irq_entries_start>:
   0:   89 e0                   mov    %esp,%eax
   2:   ba 00 00 00 00          mov    $0x0,%edx
   7:   90                      nop    
   8:   89 e0                   mov    %esp,%eax
   a:   ba 01 00 00 00          mov    $0x1,%edx
   f:   90                      nop    
  10:   89 e0                   mov    %esp,%eax
  12:   ba 02 00 00 00          mov    $0x2,%edx
  17:   90                      nop    
  18:   89 e0                   mov    %esp,%eax
  1a:   ba 03 00 00 00          mov    $0x3,%edx


What I would like to do is fill 'interrupt' with current code address (.text section), not the current data address.

I tried a few things (macros, local labels) but can't find a way to get it. Can you please help me ?

Thanks.

Greg.


PS: the following code works with the GNU assembler :

.data
interrupt:
.text

vector=0
irq_entries_start:
.rept 4
1:      pushl $(vector)
        nop
        nop

.data
        .long 1b
.text
vector=vector+1
.endr


-- 
                       _
ASCII ribbon campaign ( )
 - against HTML email  X
             & vCards / \

Re: [Nasm-users] convert this masm code to valid nasm

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

Ejaz Ahmed wrote:
> hi Frank
>     thanks my dear  for your kind help.your code worked fine with my 
> nasm.there was a problem with my gdb and it was giving errors.

I had a problem using Jeff's ".gdbinit" because of "line wrap". Once I 
got those all "unwrapped", it worked. Maybe you're having the same problem.

> so instead 
> of fixing them , i installed ald(as  u mentioned that u r using ald). it 
> was very nice.i just open tha man ald and debugged whole of programme.it 
> is an excellent debugger.

The name suggests that it might be better suited to debugging asm 
programs. I *really* should learn to use gdb. Perhaps you should, too. 
Doesn't have to be right now... :)

> i would like two things to be answered from u. 
> first is about ald and 2nd about nasm code
> 
> about ald :
>                  ald is displaying values of registers as eax ,ebx (32 
> bit x86 mpu registers) while my code used ax ,bx (8088/8086 mpu registers)
> since my course is on 8088/8086 processors ,so i would like to change 
> its display to 8086/8088 registers style. how can i do that?

I don't think there's an easy way. (modify the source and rebuild ald, 
of course...) Just hold your hand over the first four digits. :)

You might want to consider installing "dosemu". It's got a "debug-alike" 
that will look more like what you're seeing in class. David Lindauer's 
"GRDB" will let you switch between displaying 16- and 32-bit registers - 
it's "like DEBUG, only smarter"! Not for Linux, but it'll run in dosemu.

> abot nasm:
> 
>   your modified code is below
> 
> global _start

Maybe I should have explained this, too. The "global" directive tells 
Nasm to make this symbol available to the linker. Masm would use 
"public" for this, I think.

> section .text

This could also be said "segment .text". Like Masm's "code_seg segment 
'code'". "code_seg" or ".text" are just names. The "'code'" in Masm is 
the "class" - in Nasm, you'd do it like "class=code", but Nasm knows 
what ".text" is.

> _start:

This is the default entrypoint that ld knows about. Masm does it 
differently... At the end of the Masm code, I'd expect to see "end 
main". This would tell Masm to tell the linker that "main" is the 
entrypoint. (your code didn't actually do this... I'm not sure why not.)

>  nop
> 
>  mov ax,50h
>  mov bx,60h
>  mov cx,ax
>  add ax,ax    ;2*ax
>  mov dx,ax    ;dx=2ax
>  add ax,ax    ;ax=4ax
>  add ax,dx    ;ax=6ax
>  add ax,cx    ;ax=7ax
>  mov dx,ax    ;dx=7ax
>  mov cx,bx
>  add bx,bx
>  add cx,bx
>  sub dx,cx
> 
>  xor ebx, ebx  ; I didn't see an error! :)
>  mov eax, 1    ; __NR_exit
>  int 80h
> 
> 
> it worked fine.
> 
> then i modified your code as
> 
> global _start
> 
> section .text
> _start:
>  ;nop
> 
>  mov ax,50h
>  mov bx,60h
>  mov cx,ax
>  add ax,ax    ;2*ax
>  mov dx,ax    ;dx=2ax
>  add ax,ax    ;ax=4ax
>  add ax,dx    ;ax=6ax
>  add ax,cx    ;ax=7ax
>  mov dx,ax    ;dx=7ax
>  mov cx,bx
>  add bx,bx
>  add cx,bx
>  sub dx,cx
> 
>  ;xor ebx, ebx  ; I didn't see an error! :)
>  ;mov eax, 1    ; __NR_exit
>  ;int 80h
> 
> 
> it still worked and gave same output.

Okay... for stepping through in a debugger. If you tried to run it, it 
would crash. If you kept stepping in the debugger, you'd get "garbage" 
(and would eventually crash). The CPU doesn't just stop when you quit 
coding!

> so can u explain or give some link 
> to following commands which seem to be extra in this particular example
> 
>   nop
> ;u said gdb would be happier to see this. why?

As I understand it, gdb wants to replace your instruction with a 
breakpoint, "int3" instruction (0CCh). It's happier if it has a one-byte 
instruction to replace - because it doesn't have to calculate the length 
of the instruction, I suppose? I really don't know - try it with or 
without and see what you see...

> what is the meaning of 
> this command

It's "no operation" - opcode 90h. If you look at the way the instruction 
is encoded, it's actually "xchg eax, eax"... or "xchg ax, ax" in 16-bit 
code. (you may not have discovered yet that 16- and 32-bit opcodes are 
the *same* opcode...)

> is  this true for ald as well?

What I'm seeing, without the "nop", is when I "step", the first thing I 
see is "mov bx, 0x60". With the "nop" in, I start right with "mov ax, 
0x50". Not necessary, but I like it better with the "nop".

>   xor ebx,ebx ;what this is?

Ahhh... it's an "exclusive or"...

or | 0 1
--------
0  | 0 1
1  | 1 1

xor| 0 1
--------
0  | 0 1
1  | 1 0

That is, it's "true" (one) if one bit or the other is one, but not both. 
"xor"ing anything with itself (obviously?) results in zero. I shou;d 
have used "mov ebx, 0" - an instruction you know. Does the same thing - 
"xor" results in shorter code. Sorry.

Why we want ebx zeroed, is that when we do a "sys_exit" in Linux, the 
"return code" or "error code" goes in ebx. A program is "supposed to" 
return something, zero is traditional for "no error". Really doesn't 
matter in this case - I should have left it out.

>  mov eax ,1 ;this seems like moving 1 in eax exits programme (am i right)

Nearly.

>  int 80h ;what is this?

This is what actually exits the program (if eax is 1). The "int" 
("interrupt", not "integer") instruction is a complicated one, but 
you'll be needing it soon...

There's a "table of addresses" in memory (the "IVT" - Interrupt Vector 
Table"). In dos, it's usually right at the bottom of memory, at 0:0 (and 
up). Linux locates it... who knows where? We don't have to care (that's 
the point). The "int" instruction uses its operand - 80h in this case, 
21h is common in dos - as an index into this table. Each entry is four 
bytes, so "IVT + 80h * 4" would hold the address of code to implement 
Linux system calls. "IVT + 21h * 4" would be the address of code dos 
services (but not at the same time - they're quite incompatible!)

The "subfunction number" goes in eax (ah for dos). In Linux, 1 is exit, 
2 is fork, 3 is read, 4 is write, 5 is open, 6 is close... see 
"unistd.h" for the rest. And "man (2)" for what they do. The dos (and 
bios) interrupts are well documented in Ralf Brown's Interrupt List - 
huge download, but well worth it - his "ports.lst" even applies in 
Linux! :) http://www.pobox.com/~ralf IIRC.

After executing this code, the "int" instruction returns to the next 
instruction - except that "exit" doesn't return, of course.

You'll probably soon encounter code that looks something like this:

; nasm -f bin -o myprog.com myprog.asm
; no linker required

org 100h    ; this tells Nasm where dos will load us

mov ah, 9   ; the "print $-terminated string" function
mov dx, msg ; "offset msg" for Masm!
int 21h

mov ah, 4Ch  ; the "exit" subfunction
int 21h

msg db "Hello, world!$"

The "org 100h" may be unfamiliar... Dos always loads a .com file at 
some_seg:100h. When the "mov dx, msg" (or "offset msg") is assembled to 
machine code, "msg" isn't there, of course - it's been converted to a 
number. The "org" ("origin") directive tells Nasm "where to start 
counting" to calculate this number.

Try it without the "org 100h". Now try without the "org", but with "mov 
dx, msg + 100h". See what it does?

The two "int" instructions look up the address for "dos services" and 
execute that code, branching depending on what's in ah - in one case 
printing the string and returning, in the second case ending you program 
and booting you out to the dos prompt.

Same (similar) thing in Linux:

global _start

section .text
_start:

mov eax, 4       ; subfunction "write"
mov ebx, 1       ; "file handle" - standard output
mov ecx, msg     ; address of buffer
mov edx, msg_len ; number of bytes to write
int 80h          ; "call" OS services

mov eax, 1       ; subfunction "exit"
int 80h

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


> i think it would seeem hideous for u to answer these questions

Well, I've got to atone for introducing instructions you hadn't learned 
yet! :)

> (not 
> common in linux community).

No, not strictly "nasm questions" either, but they're relevant.

> so if u don't want answer these ,just give 
> me a quick start link to these commands.

The "proper" documentation for the instruction set is the manufacturer's 
manuals - Intel or AMD - not much difference at this level. But the Nasm 
manual has a section on 'em, which I find easier to use.

> thank once again for your nice reply

A pleasure to discuss assembly language! (hope I'm not confusing you 
more...)

Best,
Frank

Re: [Nasm-users] convert this masm code to valid nasm

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

ce...@ar... wrote:
> On Wed, Nov 08, 2006 at 05:03:52PM -0500, Frank Kotler wrote:
> 
>>>i am taking a first course on microprocessors. in lab we are using masm.i am 
>>>using kubuntu 6.06 at home. so i decided to use nasm.
>>
>>Two steps in the right direction!
> 
> 
>    Are you endorsing kubuntu, masm, or a course in microprocessors, Frank?

I was endorsing the dos/'doze -> Linux amd Masm -> Nasm transitions.

>    Wait -- never mind.   I see why you left it vague.  ; )
> 
> -Phil/CERisE

I suppose I should have made it three-for-three, but I've never actually 
taken a microprocessor course... :)

Best,
Frank

P.S. I assume this was supposed to go to the list. You have to hit 
"reply all" for it to go to the list. Just "reply" replies only to the 
original poster. PITA, but they strongly advise that the list be 
configured this way. I don't recall the reasoning... could change it, I 
suppose...

Re: [Nasm-users] convert this masm code to valid nasm

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

Ejaz Ahmed wrote:
> hello to all nasm users

Hi Ejaz, (cool name!)

> i am taking a first course on microprocessors. in lab we are using masm.i am 
> using kubuntu 6.06 at home. so i decided to use nasm.

Two steps in the right direction!

> since we have only 
> studied three statements commands of 8086/8088  microprocessor and our 
> instructor kept us  in abstraction and promised us to tell bout starting 
> statements after a week. so i am sending a masm code and request you to 
> convert it into a valid nasm code and also commands of gdb (or some other 
> debugger) to check the values in each register.
> here is masm code
> 
> code_seg segment 'code'
> assume cs:code_seg
> main proc far
> 
>   mov ax,50h
>   mov bx,60h
>   mov cx,ax
>   add ax,ax    ;2*ax
>   mov dx,ax    ;dx=2ax
>   add ax,ax    ;ax=4ax
>   add ax,dx    ;ax=6ax
>   add ax,cx    ;ax=7ax
>   mov dx,ax    ;dx=7ax
>   mov cx,bx
>   add bx,bx
>   add cx,bx
>   sub dx,cx
> 
> main endp
> code_seg ends
> end

The good news is that the actual "code" won't have to be changed at all. 
Some of the "cruft" at the beginning and end require some changes. Like 
so...

; nasm -f elf -g myprog.asm
; ld -o myprog myprog.o


global _start

section .text
_start:
   nop

   mov ax,50h
   mov bx,60h
   mov cx,ax
   add ax,ax    ;2*ax
   mov dx,ax    ;dx=2ax
   add ax,ax    ;ax=4ax
   add ax,dx    ;ax=6ax
   add ax,cx    ;ax=7ax
   mov dx,ax    ;dx=7ax
   mov cx,bx
   add bx,bx
   add cx,bx
   sub dx,cx

   xor ebx, ebx  ; I didn't see an error! :)
   mov eax, 1    ; __NR_exit
   int 80h


Notice I've added an explicit "exit" (first thing we have to learn is 
how to exit!) The "nop" at the beginning is a "parking place for gdb". 
Gdb is happier if there's a one-byte opcode to stop on.

The bad news is that I can't get gdb to step through it right now. I 
think I've done it before... I'm not smart enough to run gdb. I use ald, 
Patrick Alken's "Assembly Language Debugger" (SourceForge), and an older 
version (0.1.7) at that, because it's "more like debug". Faint praise, 
that I like a debugger 'cause it's "more like debug"... But the only 
command I need is "step"...

I know that you can make gdb a little more "Nasm-friendly" by having a 
".gdbinit" file in your home directory... Here's one that Jeff Owens 
posted, some time ago...


# gdb initialization file, it must reside at ~/.gdbinit or ./.gdbinit
#
# define special help command "h" that shows asm related commands only
#
define h
echo -------\n
echo asm debugging commands, see "help" for other gdb comands\n
echo \ \n
echo g <adr>  exec & set temp break <adr>     u <n> disassemble from pc 
n times\n
echo c  run program (continue)                uu <adr> <n> disassemble 
from adr n times\n
echo n  step one instruction                  ss <n> show stack n 
locations\n
echo nn  step but do not enter calls          r  show registers\n
echo until  step or run to end of loop        db <adr> <n> display bytes\n
echo \                                         dw <adr> <n> display words\n
echo q  quit gdb                              dd <adr> <n> display dword\n
echo \                                         ds <adr> <n> display string\n
echo bs  show breaks                                                      \n
echo bc  clear breaks                                                     \n
echo                                                                      \n
echo modifying the code within gdb requires reload, recompile easier? \n
echo to change register -> set $eax = 0x123456 \n
echo ------\n
end
#
# set gdb initialization flags - change these as needed
#
# eliminate the pesky exit message that says program is running
set confirm off
set language asm
set disassembly-flavor intel
# enable the following to work in hex, the default is decimal
set output-radix 16
set input-radix 16
#
# disable pesky hook messages?? this may not be necessary in other 
versions of gdb
#
define hook-stop
end
define hook-continue
end
#------------- define special commands for assembler -------------------
#
# go (run) to temporary break location "g <label>"
#
define g
tbreak $arg0
continue
x/1i $pc
echo ----------\n
end
#
# show stack  "ss <n>" where n is number of entries to show
#
define ss
x/$arg0xh $esp-(4 * $arg0)
end
#
# define nn to single step over calls
#
define nn
echo --------------
exti
printf "eax=%x ebx=%x ecx=%x edx=%x esi=%x edi=%x ebp=%x
esp=%x\n",$eax,$ebx,$ecx,$edx,$esi,$edi,$ebp,$esp
x /4i $pc
end
#
# define n to single step one instruction
#
define n
echo ---------------
si
printf "eax=%x ebx=%x ecx=%x edx=%x esi=%x edi=%x ebp=%x esp=%x
eflags=%x\n",$eax,$ebx,$ecx,$edx,$esi,$edi,$ebp,$esp,$eflags
#disassemble $pc $pc+14
x /4i $pc
end
#
# define "u <n>"  to disassemble n locations from $pc
#
define u
x/$arg0i $eip
# disassemble $eip $eip+$arg0
  end
#
# define "uu <label> <n>"  to disasseble n locatons from given label
#
define uu
x/$arg1i $arg0
# disassemble $arg0 $arg0+$arg1
  end
#
# define "bs" show breaks
#
define bs
info break
end
#
# define "bc" clear all breakpoints
#
define bc
delete
end
#
# define "r" show  registers
#
define r
echo -----\n
printf "eax=%x ebx=%x ecx=%x edx=%x esi=%x edi=%x
ebp=%x\n",$eax,$ebx,$ecx,$edx,$esi,$edi,$ebp
printf "esp=%x   eip=%x   flag=%x -->     O D I T   S Z - AC   - P - 
C\n",$esp,$eip,$eflags
echo flags= Overflow, Direction, Interrupt, Trap, Sign, Zero, AuxCarry, 
Parity, Carry\n
x/i $pc
echo -----\n
end
#
# define "db <adr> <n>"  display <n> bytes at <adr>
#
define db
x/$arg1xb $arg0
end
#
# define "dw <adr> <n>"  display <n> words at <adr>
#
define dw
x/$arg1xh $arg0
end
#
# define "dd <adr> <n>"  display <n> dwords at <adr>
#
define dd
x/$arg1xw $arg0
end
#
# define "ds <adr> <n>"  display <n> char(ascii) at <adr>
#
define ds
x/$arg1xc $arg0
end
#
# start of code initialization ----------------------
#
# to initialize gdb we need to use the "run" command once, first
# we display the current instruction, then set a break at next location.
# Warning - the first instruction must be one byte long.
# Next, we start t# gdb initialization file, it must reside at 
~/.gdbinit or ./.gdbinit
#
# define special help command "h" that shows asm related commands only
#
define h
echo -------\n
echo asm debugging commands, see "help" for other gdb comands\n
echo \ \n
echo g <adr>  exec & set temp break <adr>     u <n> disassemble from pc 
n times\n
echo c  run program (continue)                uu <adr> <n> disassemble 
from adr n times\n
echo n  step one instruction                  ss <n> show stack n 
locations\n
echo nn  step but do not enter calls          r  show registers\n
echo until  step or run to end of loop        db <adr> <n> display bytes\n
echo \                                         dw <adr> <n> display words\n
echo q  quit gdb                              dd <adr> <n> display dword\n
echo \                                         ds <adr> <n> display string\n
echo bs  show breaks                                                      \n
echo bc  clear breaks                                                     \n
echo                                                                      \n
echo modifying the code within gdb requires reload, recompile easier? \n
echo to change register -> set $eax = 0x123456 \n
echo ------\n
end
#
# set gdb initialization flags - change these as needed
#
# eliminate the pesky exit message that says program is running
set confirm off
set language asm
set disassembly-flavor intel
# enable the following to work in hex, the default is decimal
set output-radix 0x10
set input-radix 0x10
#
# disable pesky hook messages?? this may not be necessary in other 
versions of gdb
#
define hook-stop
end
define hook-continue
end
#------------- define special commands for assembler -------------------
#
# go (run) to temporary break location "g <label>"
#
define g
tbreak $arg0
continue
x/1i $pc
echo ----------\n
end
#
# show stack  "ss <n>" where n is number of entries to show
#
define ss
x/$arg0xh $esp-(4 * $arg0)
end
#
# define nn to single step over calls
#
define nn
echo --------------
exti
printf "eax=%x ebx=%x ecx=%x edx=%x esi=%x edi=%x ebp=%x 
esp=%x\n",$eax,$ebx,$ecx,$edx,$esi,$edi,$ebp,$esp
x /4i $pc
end
#
# define n to single step one instruction
#
define n
echo line-
si
printf "eax=%x ebx=%x ecx=%x edx=%x esi=%x edi=%x ebp=%x esp=%x 
eflags=%x\n",$eax,$ebx,$ecx,$edx,$esi,$edi,$ebp,$esp,$eflags
#disassemble $pc $pc+14
x /4i $pc
end
#
# define "u <n>"  to disassemble n locations from $pc
#
define u
# x/$arg0i $eip
# disassemble $eip $eip+$arg0
disassemble $arg0
  end
#
# define "uu <label> <n>"  to disassemble n locations from given label
#
define uu
x/$arg1i $arg0
# disassemble $arg0 $arg0+$arg1
  end
#
# define "bs" show breaks
#
define bs
info break
end
#
# define "bc" clear all breakpoints
#
define bc
delete
end
#
# define "r" show  registers
#
define r
echo -----\n
printf "eax=%x ebx=%x ecx=%x edx=%x esi=%x edi=%x 
ebp=%x\n",$eax,$ebx,$ecx,$edx,$esi,$edi,$ebp
printf "esp=%x   eip=%x   flag=%x -->     O D I T   S Z - AC  - P - 
C\n",$esp,$eip,$eflags
echo flags= Overflow, Direction, Interrupt, Trap, Sign, Zero, AuxCarry, 
Parity, Carry\n
x/i $pc
echo -----\n
end
#
# define "db <adr> <n>"  display <n> bytes at <adr>
#
define db
x/$arg1xb $arg0
end
#
# define "dw <adr> <n>"  display <n> words at <adr>
#
define dw
x/$arg1xh $arg0
end
#
# define "dd <adr> <n>"  display <n> dwords at <adr>
#
define dd
x/$arg1xw $arg0
end
#
# define "ds <adr> <n>"  display <n> char(ascii) at <adr>
#
define ds
x/$arg1cb $arg0
end

# attempt a string display...
define dstr
x /1sb &$arg0
end


#
# start of code initialization ----------------------
#
# to initialize gdb we need to use the "run" command once, first
# we display the current instruction, then set a break at next location.
# Warning - the first instruction must be one byte long.
# Next, we start the program executing (run) then clear all breakpoints.
#

# x /1i *_start
# echo ---------------
# break *_start+1
# run
# delete
# x /1i *_start+1

echo \n---------\n
echo for some reason nasm symbols appear as functions?  ignore\n
echo symbol related warnings.\n
echo \n
echo -------- ty%s, %s%s


Good luck with it. If all else fails, we can come up with a routine to 
*print* the damn value (even call printf, if we want to)...

Best,
Frank

[Nasm-users] convert this masm code to valid nasm

[Ejaz A. <u0...@ho...>]

hello to all nasm users

i am taking a first course on microprocessors. in lab we are using masm.i am 
using kubuntu 6.06 at home. so i decided to use nasm.since we have only 
studied three statements commands of 8086/8088  microprocessor and our 
instructor kept us  in abstraction and promised us to tell bout starting 
statements after a week. so i am sending a masm code and request you to 
convert it into a valid nasm code and also commands of gdb (or some other 
debugger) to check the values in each register.
here is masm code

code_seg segment 'code'
assume cs:code_seg
main proc far

  mov ax,50h
  mov bx,60h
  mov cx,ax
  add ax,ax    ;2*ax
  mov dx,ax    ;dx=2ax
  add ax,ax    ;ax=4ax
  add ax,dx    ;ax=6ax
  add ax,cx    ;ax=7ax
  mov dx,ax    ;dx=7ax
  mov cx,bx
  add bx,bx
  add cx,bx
  sub dx,cx

main endp
code_seg ends
end

_________________________________________________________________
All-in-one security and maintenance for your PC.  Get a free 90-day trial! 
http://clk.atdmt.com/MSN/go/msnnkwlo0050000002msn/direct/01/?href=http://www.windowsonecare.com/?sc_cid=msn_hotmail

Re: [Nasm-users] [Nasm-devel] SETING PROBLEM OF NASM ON INTEL MACHINE

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

Manu Rastogi, Noida wrote:
> Dear sir/madam ,
> 
> I really need your help . I am trying to build the visual C++ workspace 
> on intel machine . This workspace has  got some x86 assembly files which 
> is to compiled but I am *not* able to compile these assembly file . the 
> error I am getting is as follows
> 
>  
> 
> performing Custom Build Step on ..\blit\blit_mmx.asm
> 
> 'nasm' is not recognized as an internal or external command,
> 
> operable program or batch file.
> 
> Error executing c:\winnt\system32\cmd.exe.
> 
>  
> 
> blit_mmx.obj - 1 error(s), 0 warning(s)
> 
>  
> 
> similarily for other Visual C++ workspace I am getting similar error
> 
>  
> 
> -------------------Configuration: libxvidcore - Win32 
> Debug--------------------
> 
> Assembling ...\..\src\utils\x86_asm\mem_transfer_mmx.asm
> 
> 'nasm' is not recognized as an internal or external command,
> 
> operable program or batch file.
> 
> Error executing c:\winnt\system32\cmd.exe.
> 
>  
> 
> xvidcore.dll - 1 error(s), 0 warning(s)
> 
>  
> 
> please help me in this regard at your earnest.

Hi Manu,

I'm transferring your query from the "nasm-devel" list to the 
"nasm-users" list, since this doesn't seem to be a "Nasm problem".

I'm not familiar with Visual C++, or with modern Windows versions, but 
it sounds as if Nasm isn't on your path. One thought: the Windows build 
of Nasm is usually named "nasmw.exe" (for no good reason?). If VC++ is 
looking for "nasm.exe", this could be a problem. Either renaming 
"nasmw.exe" to "nasm.exe" or telling VC++ "nasmw" should fix that 
problem. You may need to put the directory where nasm/nasmw resides on 
your path, or perhaps giving VC++ the full path to nasm(w) would do it.

Maybe some VC++/nasm user can provide better suggestions.

Best,
Frank

[Nasm-users] nasm_man.chm

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

I have uploaded Jim Carlock's conversion of the Nasm Manual to:

http://groups.yahoo.com/group/win32-nasm-users
http://sf.net/projects/nasm
http://home.comcast.net/~fbkotler/nasm_man.zip

(in the "files" section of the first two urls - "contributions" section 
at SF, "chm docs" at !Yahoo!)

Since I can't boot 'doze at the moment, someone is going to have to tell 
me whether it works or not. Since neither I nor the nasm-devel team are 
going to maintain this thing, someone is going to have to update it to 
reflect any major changes to Nasm (shouldn't be much of a problem at the 
rate Nasm is changing lately :)

Big thanks to Jim for creating this!!!

Best,
Frank

Re: [Nasm-users] Complete newbie question

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

Frank Kotler wrote:
> ce...@ar... wrote:
>> Hello again!
>>
>> I seem to have run into another problem with the nasm-human interface.
>> I've got code loaded into es:bx, courtesy of int 13.
>>
>> My understanding is that I ought to be able to far jump to es:bx, however
>> jmp es:bx gets me the error "invalid combination of opcode and operands".
>>
>> For fun, I replaced es:bx with 0xFFFF:0xFFFF which worked OK (although,
>> FFFFh:FFFFh doesn't -- nasm parses that first FFFFh as a label).  I then
>> tried 0xFFFF:bx and es:0xFFFF, both of which gave me the same invalid
>> combination of opcodes and operands.
>>
>> Here's a listing of things which I've tried while trying to figure out 
>> the
>> problem.
>> jmp cs:0xFFFF
>> jmp ds:0xFFFF
>> jmp es:bx
>> jmp bx:dx
>> jmp ebx:edx
>> jmp ds:dx
>>
>> These two complain about operation size not being specified.  Including
>> dword after jmp brings back the invalid combination error.
>> jmp 0xFFFF:bx  jmp 0xFFFF:ebx
>>
>> Incidentally, [cs:0xFFFF] and [ds:0xFFFF] will work, although that's 
>> nothing even approximating what I want. 
> 
> Hi Phil,
> 
> You've pretty much run the gamut! The only kind of "jmp xxxx:xxxx" is 
> "imm:imm". As you know "jmp [xxx]" is a different thing. If you've got a 
> target address in es:bx, your choices are to put 'em in a memory 
> location "mov [target], bx"/"mov [target + 2], es"/"jmp far [target]", 
> or "push es"/"push bx"/"retf". I don't *know* of any other way to do 
> it.... Well, typically in a bootsector, we know what went into es and bx 
> before the int 13h, so we can do "jmp imm:imm"...
> 

A common way to jump to say ES:BX is:

	push es
	push bx
	retf

	-hpa

Re: [Nasm-users] Complete newbie question

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

ce...@ar... wrote:
> Hello again!
> 
> I seem to have run into another problem with the nasm-human interface.
> I've got code loaded into es:bx, courtesy of int 13.
> 
> My understanding is that I ought to be able to far jump to es:bx, however
> jmp es:bx gets me the error "invalid combination of opcode and operands".
> 
> For fun, I replaced es:bx with 0xFFFF:0xFFFF which worked OK (although,
> FFFFh:FFFFh doesn't -- nasm parses that first FFFFh as a label).  I then
> tried 0xFFFF:bx and es:0xFFFF, both of which gave me the same invalid
> combination of opcodes and operands.
> 
> Here's a listing of things which I've tried while trying to figure out the
> problem.
> jmp cs:0xFFFF
> jmp ds:0xFFFF
> jmp es:bx
> jmp bx:dx
> jmp ebx:edx
> jmp ds:dx
> 
> These two complain about operation size not being specified.  Including
> dword after jmp brings back the invalid combination error.
> jmp 0xFFFF:bx  
> jmp 0xFFFF:ebx
> 
> Incidentally, [cs:0xFFFF] and [ds:0xFFFF] will work, although that's nothing 
> even approximating what I want. 

Hi Phil,

You've pretty much run the gamut! The only kind of "jmp xxxx:xxxx" is 
"imm:imm". As you know "jmp [xxx]" is a different thing. If you've got a 
target address in es:bx, your choices are to put 'em in a memory 
location "mov [target], bx"/"mov [target + 2], es"/"jmp far [target]", 
or "push es"/"push bx"/"retf". I don't *know* of any other way to do 
it.... Well, typically in a bootsector, we know what went into es and bx 
before the int 13h, so we can do "jmp imm:imm"...

Best,
Frank

Re: [Nasm-users] Complete newbie question

[<ce...@ar...>]

Hello again!

I seem to have run into another problem with the nasm-human interface.
I've got code loaded into es:bx, courtesy of int 13.

My understanding is that I ought to be able to far jump to es:bx, however
jmp es:bx gets me the error "invalid combination of opcode and operands".

For fun, I replaced es:bx with 0xFFFF:0xFFFF which worked OK (although,
FFFFh:FFFFh doesn't -- nasm parses that first FFFFh as a label).  I then
tried 0xFFFF:bx and es:0xFFFF, both of which gave me the same invalid
combination of opcodes and operands.

Here's a listing of things which I've tried while trying to figure out the
problem.
jmp cs:0xFFFF
jmp ds:0xFFFF
jmp es:bx
jmp bx:dx
jmp ebx:edx
jmp ds:dx

These two complain about operation size not being specified.  Including
dword after jmp brings back the invalid combination error.
jmp 0xFFFF:bx  
jmp 0xFFFF:ebx

Incidentally, [cs:0xFFFF] and [ds:0xFFFF] will work, although that's nothing 
even approximating what I want. 

-Phil/CERisE

Re: [Nasm-users] Complete newbie question

[<ce...@ar...>]

On Wed, Apr 05, 2006 at 11:03:16PM -0400, Frank Kotler wrote:
> You're on the right track here. *Now* the problem is that ds is involved 
> (I spoke too soon, above) - "lds si, [ds:ptr]" is what is implied here 
> (you wouldn't want to write it that way, or Nasm would emit a redundant 
> segment prefix, but that's what it "means").

   I just realized why it won't work (and truly, I feel like a moron for wasting
your time on it) -- the assembler doesn't know that the code's going to be 
loaded into 7c00 without my say-so.  That's my entire problem right there.
 
> Not sure why you'd "shr eax, 16" - "shr eax, 4" would've been closer... 
> but that won't really do it... might if you're lucky... and "seg" is for 
> linkable object formats... "-f bin" doesn't have "segments" in the same 
> sense. We can say "segment .text" or "section .text" - exactly the same 
> thing to Nasm, but I prefer the latter. Nasm re-arranges our "sections" 
> (.text first, .data next, .bss last), but they aren't put in separate 
> "segments"...

   I was skeptical, so I ran it -- shr eax, 4 doesn't work.  My reasoning for 16
was that if message's absolute address is 00007c03, then 0000 should be in the 
segment register and 7c03 should be in the index.

> And put it in ds. Sure enough, 0000:7C03 is where the message lives! 
> "message" just evaluates to 3, since Nasm defaults to "org 0" if you 
> don't specify. That would be okay, too - but we would want to load ds 
> with 7C0h in that case. 07C0:0003 is the *same* address!

   I might be misunderstanding, but my attempt at setting up the address as
07c0:0003 isn't pointing at the right place.  Again, my understanding was that
the segment and index are discrete parts of the 32 bit address where the
message is located.  Is that incorrect?
   I tried this:
mov si, 0x0003
mov ax, 0x07c0
mov ds, ax
call putstr
   Going with the assumption that you meant 7c00 instead of 07c0 doesn't work
either.  My understanding appears to be correct here that ds specifies the
upper 16 bits of the memory access and si specifies the lower 16 bits.
 
> Okay... no "org", so we've got "org 0". The "other way" (more common, 
> perhaps) is "org 7C00h"... we just need to do something different with 
> ds. The bios does *not* set it up for us!

   So let's run with this.  The data I want is in code space.  In order to
execute the code, cs ought to be set correctly.  So if I run:
mov si, message
mov ax, cs
mov ds, ax
call putstr
   message shows up as 0x0003 in this case, which makes sense given that the 
assembler doesn't know that the BIOS is going to throw this code into 0x7c00.
   It appears to me that since the proper segment is 0x0000, I'll need to find
out what my initial address is and use that as a base for all my accesses.  This
may be entirely crazy, but I'm calling a function, popping bx, subtracting the 
size of the call instruction from bx, and making all references to data as 
bx+variable, though I apparently can't do that outside of a dereference.
   Is there a better way to go than mov si, bx / add si, message? 

> Okay... you may have done yourself a favor here. The "canonical" 
> bootsector starts with either a "jmp" (near), or "jmp short ..."/"nop", 
> and the "oem string" starts after that. I've never seen it, but I've 
> heard of a bios that refuses to boot without it. What you jump over is 
> up to you - there are advantages to making your disk FAT12 compatible...

   Interesting.  I hadn't heard that before.  I knew there was a signature
on the bootsector that was required, but that's it.  I've been against that
method just because of the additional jump.  Thanks 8)
 
> Maybe want to load other segregs here too. In particular, you'll want to 
> know where your stack is! Presumably, the bios has got ss:sp pointed 
> someplace "sane" - interrupts, the timer and stuff, use the stack, so we 
> *can't* have it pointed where it'll scribble on important stuff, even if 
> we don't use it. Best get it under our control, ASAP. (but for this 
> example... ignore the issue :)

   The system in hand has ss=0, sp=0xFFFE which is sufficient for the moment.
 
> This only stays "hlt"ed until an interrupt occurs. You might want to do:
> 
> stop:
> hlt
> jmp stop
> 
> Another possibility... "int 19h" reloads the bootsector... you might 
> want to "wait for a key", and then "int 19h" to "see it again" for 
> debugging purposes (doesn't help that much...).

   ATM, the hlt is there until I go on to bigger and better things.  I'm
satisfied with trying to make putstr work for the moment ; )
   In my case, I've been running this via bochs (which seems to mimic the
real system in all the important ways), so rebooting's really nice & easy.
 
> *Some* video biosen (I'm told) use bl as the "attribute" (color) to use. 
> Most use the default white-on-black (7). More commonly, bh is used as 
> the "video page" to write to - other biosen write to whatever page is 
> "current" (0, ... "always", AFAIK). My bios writes white-on-black to the 
> current page regardless of what's in bx. For "maximum safety", I'd go 
> with "mov bx, 7". No need to use ebx.

   I was purposely aiming for 0 on the theory that I can read what the BIOS
prints, so current can't be too bad a choice.  7 is sensible though.  I'll
keep that in mind.
   Lest it doesn't come out through this email, thanks a ton for helping
me out.  The subsequent explanations beyond "NASM can't know a priori where
the code is being loaded" are well beyond your duties as a maintainer.
 
-Phil/CERisE

Re: [Nasm-users] Complete newbie question

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

cerise-nasm@l.armory.com wrote:
> I'm using nasm 0.98.39 and I'm trying to assemble plain binary
> which will spit out a string when plopped onto a floppy disk and made to
> boot.
> 
> I've done this a couple of different ways, but what I'd really like to do
> is have the string pointed to by ds:si.
> 
> The string is defined as:
> message db "Hello!", 0x0D, 0x0A, 0x00
> 
> I've tried:
> lds si, message (invalid comination of opcode and operands)

Right. "lds" needs a "[memory]" operand. "message" is just an 
"immediate" number.

> lds si, [message] (which gives ds:si f000:ff56, not 0000:7c03)

The problem here is that, even though this loads ds, it implicitly loads 
it from [ds:message] - and ds doesn't yet have a meaningful value. 
(it'll be the same every time on *your* machine, of course, but will 
likely differ on another machine). "[message]" would want to be "[ptr]" 
here, anyway...

> The latter struck me as odd because I took [message] to be accessing the 
> memory address contained in message, not the address of message -- which
> isn't what I want.

Well... "lea reg, [message]" would load the address into "reg" (as would 
the shorter "mov reg, message"). "lds", "les", "lss" etc. look similar, 
but they load a segreg *and* "reg" with the contents of a "far pointer".

> I also attempted defining a pointer (ptr dw message, 0) and using
> lds si, [ptr] which inexplicably gives me f000:ff53.

You're on the right track here. *Now* the problem is that ds is involved 
(I spoke too soon, above) - "lds si, [ds:ptr]" is what is implied here 
(you wouldn't want to write it that way, or Nasm would emit a redundant 
segment prefix, but that's what it "means").

*All* addresses on x86 involve a segment register. (e)ip uses cs, of 
course, (e)sp and (e)bp default to ss, the "destination" on the "string 
instructions" is es:(e)di. Otherwise ds:??? is the default. This is true 
even in 32-bit pmode - segregs are used differently, and most OSen allow 
us to ignore 'em entirely (which is a *great* blessing!), but they're 
still involved in *every* address.

> I also tried setting it through eax (mov eax, message ; mov si, ax ; 
> shr eax, 16 ; mov ds, ax ) with no luck.  I tried setting ds to seg message
> and si to message, but I can't use seg in plain binary.

Not sure why you'd "shr eax, 16" - "shr eax, 4" would've been closer... 
but that won't really do it... might if you're lucky... and "seg" is for 
linkable object formats... "-f bin" doesn't have "segments" in the same 
sense. We can say "segment .text" or "section .text" - exactly the same 
thing to Nasm, but I prefer the latter. Nasm re-arranges our "sections" 
(.text first, .data next, .bss last), but they aren't put in separate 
"segments"...

> Using the tremendous power of mathematics, I can do 
> mov eax, 0x00007c03
> mov si, ax

Okay... so far you've got the same thing as "mov si, 7C03h".

> shr eax, 16

Now we make ax 0.

> mov ds, ax

And put it in ds. Sure enough, 0000:7C03 is where the message lives! 
"message" just evaluates to 3, since Nasm defaults to "org 0" if you 
don't specify. That would be okay, too - but we would want to load ds 
with 7C0h in that case. 07C0:0003 is the *same* address!

> call putstr
> 
> and I get my string AOK, but there is seemingly no symbolic form I can use.
> What is the correct form to make this work?  I'd prefer to let the computer
> do the adding.  8)

Yes.

> -Phil/CERisE
> 
> P.S.  If you really want to see the rather amateurish code,

Yes, I do! I want to see what you've got for an "org", if any, and what 
you do with segregs on startup... at least...

> here it is.  I used
> to have message right after the hlt command, but when plain arithmetic became
> a necessity, I used the more conventional format.  I've also tried all my
> labels with :s -- odd that it's optional, but kinda cool.  I imagine it'll
> bite me hard some day when I mistype an identifier in a ton of code though.  8)

Yeah. Argueably, "-w+orphan-labels" should have been the default. 
Instead, it's "off" by default. One guy thought he'd discovered a bug in 
Nasm - he mis-spelled some floating-point instruction, one with no 
parameters, and Nasm quietly accepted it (as a label). He observerd that 
*anything* starting with 'f' was okay (in fact, *anything* is, unless 
it's an instruction that expects parameters), and thought Nasm was 
assembling "fgarbage" as a floating-point instruction! As you say, it's 
kinda cool to have colons optional, but for "human clarity", I think 
it's best to use 'em... and maybe turn that warning on.

Okay... no "org", so we've got "org 0". The "other way" (more common, 
perhaps) is "org 7C00h"... we just need to do something different with 
ds. The bios does *not* set it up for us!

> jmp start

Okay... you may have done yourself a favor here. The "canonical" 
bootsector starts with either a "jmp" (near), or "jmp short ..."/"nop", 
and the "oem string" starts after that. I've never seen it, but I've 
heard of a bios that refuses to boot without it. What you jump over is 
up to you - there are advantages to making your disk FAT12 compatible...

> message db "Hello!", 0x0D, 0x0A, 0x00
> ptr dw message, 0
> 
> start 

mov ax, 7C0h
mov ds, ax
...
Maybe want to load other segregs here too. In particular, you'll want to 
know where your stack is! Presumably, the bios has got ss:sp pointed 
someplace "sane" - interrupts, the timer and stuff, use the stack, so we 
*can't* have it pointed where it'll scribble on important stuff, even if 
we don't use it. Best get it under our control, ASAP. (but for this 
example... ignore the issue :)

If you'd used "org 7C00h", we'd want 0 in ds here, so "xor ax, ax" 
instead...

> lds si, [ptr]

This would work now, but we don't need it (we'd want the segment part of 
the far pointer to be 7C0h, not 0).

> ;mov eax, 0x00007c03
> ;mov si, ax
> ;shr eax, 16
> ;mov ds, ax

mov si, message

> call putstr
> hlt

This only stays "hlt"ed until an interrupt occurs. You might want to do:

stop:
hlt
jmp stop

Another possibility... "int 19h" reloads the bootsector... you might 
want to "wait for a key", and then "int 19h" to "see it again" for 
debugging purposes (doesn't help that much...).

> putstr
> mov ah, 0x0E
> xor ebx, ebx

*Some* video biosen (I'm told) use bl as the "attribute" (color) to use. 
Most use the default white-on-black (7). More commonly, bh is used as 
the "video page" to write to - other biosen write to whatever page is 
"current" (0, ... "always", AFAIK). My bios writes white-on-black to the 
current page regardless of what's in bx. For "maximum safety", I'd go 
with "mov bx, 7". No need to use ebx.

> putloop
> lodsb
> or al, al
> jz putend
> 
> int 0x10
> jmp putloop
> 
> putend
> ret

... and I think that should make it work...

Happy bootin',
Frank

[Nasm-users] Complete newbie question

[cerise-nasm@l.armory.com]

I'm using nasm 0.98.39 and I'm trying to assemble plain binary
which will spit out a string when plopped onto a floppy disk and made to
boot.

I've done this a couple of different ways, but what I'd really like to do
is have the string pointed to by ds:si.

The string is defined as:
message db "Hello!", 0x0D, 0x0A, 0x00

I've tried:
lds si, message (invalid comination of opcode and operands)
lds si, [message] (which gives ds:si f000:ff56, not 0000:7c03)

The latter struck me as odd because I took [message] to be accessing the 
memory address contained in message, not the address of message -- which
isn't what I want.

I also attempted defining a pointer (ptr dw message, 0) and using
lds si, [ptr] which inexplicably gives me f000:ff53.

I also tried setting it through eax (mov eax, message ; mov si, ax ; 
shr eax, 16 ; mov ds, ax ) with no luck.  I tried setting ds to seg message
and si to message, but I can't use seg in plain binary.

Using the tremendous power of mathematics, I can do 
mov eax, 0x00007c03
mov si, ax
shr eax, 16
mov ds, ax
call putstr

and I get my string AOK, but there is seemingly no symbolic form I can use.
What is the correct form to make this work?  I'd prefer to let the computer
do the adding.  8)

-Phil/CERisE

P.S.  If you really want to see the rather amateurish code, here it is.  I used
to have message right after the hlt command, but when plain arithmetic became
a necessity, I used the more conventional format.  I've also tried all my
labels with :s -- odd that it's optional, but kinda cool.  I imagine it'll
bite me hard some day when I mistype an identifier in a ton of code though.  8)

jmp start
message db "Hello!", 0x0D, 0x0A, 0x00
ptr dw message, 0

start 
lds si, [ptr]
;mov eax, 0x00007c03
;mov si, ax
;shr eax, 16
;mov ds, ax
call putstr
hlt

putstr
mov ah, 0x0E
xor ebx, ebx

putloop
lodsb
or al, al
jz putend

int 0x10
jmp putloop

putend
ret