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