Assembly Language - int $0x80

[vijayanand_sodadasi]

I am learning assembly language programming. Here is the first program which does nothing but exits and returns 0.

.section .data
.section .text
.globl _start
_start:
movl $1, %eax # this is the linux kernel command
                    # number (system call) for exiting
                    # a program
movl $0, %ebx # this is the status number we will
                    # return to the operating system.
                    # Change this around and it will
                    # return different things to
                    # echo $?
int $0x80        # this wakes up the kernel to run 
                    # the exit command

What is the significance of $0x80. I mean why is only 0x80 is used as the interrupt number and why not any other number?

I am using the book Programming from the Ground Up which can be freely downloaded from here http://download.savannah.gnu.org/rel...0-booksize.pdf

[PhairOh]

Read page 27 of the book you posted (page 33 of the pdf). It has your explanation.

[rplantz]

Or, as I've said in the book I'm writing:

Calling a function that is embedded in the operating system is accomplished through a
special type of instruction sometimes called a “software interrupt.” The instruction itself
will be discussed in Section 15.3 (page 291), but it is easy to understand its use at this
point. The technique involves moving the arguments to specific registers, placing a special
code in the eax register, and then using the int $0x80 instruction to “call” a function in
the operating system. The operating system will perform the action specified by the code
in the eax register, using the arguments passed in the other registers. The values required
for reading from and writing to files are given in Table 7.2.

Table 7.2: Register set up for system calls to read or write.
      system call   eax   ebx             ecx                edx
      -----------   ---   ---             ---                ---
      read          3     file descriptor  pointer to place   number of bytes
                                          to store bytes     to read
      write         4     file descriptor  pointer to first    number of bytes
                                          byte to write      to write

[vijayanand_sodadasi]

Thanks for your replies.
So the interrupt number 0x80 is linux specific right. I mean if I were to write an assembly language program in DOS or some other OS for that matter, I must use the interrupt number specific to that operating system. Am I correct?

Thanks again for your replies.
vijay

[rplantz]

Thanks for your replies.
So the interrupt number 0x80 is linux specific right. I mean if I were to write an assembly language program in DOS or some other OS for that matter, I must use the interrupt number specific to that operating system. Am I correct?

Thanks again for your replies.
vijay

Correct. When the OS is starting up is loads the interrupt vector table. You have to know which interrupt number to use for the particular OS. I've never programmed under DOS (by choice), but according to one of my assembly language books the vector number for output to the screen is 0x21.

[LordHunter317]

Rather, the main DOS interrupt vector is 0x21.

[runcoder_en]

yes.
each os have different os soft interrupt.
especially assembly can't port easily!

[texaswriter]

yes.
each os have different os soft interrupt.
especially assembly can't port easily!

I always wondered about the imagination of people when they speak of assembly like its a spent [insert spent item here].

Well, $OS_interrupt_vector would be a stand-in. OS portability solved. Took me a microsecond to think up and a few seconds to type up.

The text editor could even have several $[ stand-ins]... so when you pushed $, a little menu popped up with the most used [followed by all the rest].... oooh!!!! dreamy!!!

Not that I'm saying people should all go jump into assembly, but arbitrarily saying assembly can't port is just plain unimaginative. Any problem is itself its own solution, just in a different form. Even something as complicated as a rubics cube is its own solution. Just have to puzzle it out.

[schauerlich]

I always wondered about the imagination of people when they speak of assembly like its a spent [insert spent item here].

Well, $OS_interrupt_vector would be a stand-in. OS portability solved. Took me a microsecond to think up and a few seconds to type up.

The text editor could even have several $[ stand-ins]... so when you pushed $, a little menu popped up with the most used [followed by all the rest].... oooh!!!! dreamy!!!

Not that I'm saying people should all go jump into assembly, but arbitrarily saying assembly can't port is just plain unimaginative. Any problem is itself its own solution, just in a different form. Even something as complicated as a rubics cube is its own solution. Just have to puzzle it out.

That said, it's much easier to port a python program than an assembly program. Especially if you need it on your G5 Mac.

[texaswriter]

That said, it's much easier to port a python program than an assembly program. Especially if you need it on your G5 Mac.

I wouldn't doubt it. My intention was not so much to compare the portability of one language to another, but to say that assembly can be just as portable as any language.

For example, you could even create an assembly language that used generic opcodes and then at compile time the compiler would insert actual registry names and use "macros" when a certain opcode wasn't supported, even allowing complex code to be ported to simpler platforms. The vast majority of computers going back [many many decades] all have the same families of basic opcodes [also called mnemonics]. Abstracting specific registers and implementations [memory registers, memory to register, register to memory, register to register, memory to memory, etc] could allow someone to use their own arbitrary set of registers. You could have an add this, that where this was a memory location and that was something else. If the intended platform didn't support adding memory locations, it would be translated to: ld register, memory address; ld register2, memory address; add register1, register2; and then another ld to put it in a memory address. NOTE: ld = mov;

Not saying this is *how* it should be implemented, but it is one easy method that allows assembly code to be robust and platform independent.