hn-classics/_stories/2001/12330970.md

created_at	title	url	author	points	story_text	comment_text	num_comments	story_id	story_title	story_url	parent_id	created_at_i	_tags	objectID	year
2016-08-21T14:09:15.000Z	Int 80h (2001)	http://www.int80h.org	joubert	63			51					1471788555	story author_joubert story_12330970	12330970	2001

Source

int80h.org -- Unix Assembly Language Programming

This Site The Web Message Boards Stock Quotes Tech News

What is int 80h?

by G. Adam Stanislav
Whiz Kid Technomagic

On the Intel family of microprocessors, such as the Pentium, int 80h is the assembly language op code for interrupt 80h. This is the syscall interrupt on a typical Intel-based Unix system, such as FreeBSD. It allows application programmers to obtain system services from the Unix kernel.

The Unix kernel services handle such things as the opening and closing of files, accessing various devices, reading from and writing to the terminal, starting new processes, etc. Without these services, every single program would have to do it on its own. The programmer would spend so much time interfacing with the computer hardware that he/she would have little energy left to concentrate on whatever his/her software is meant to do.

Such was, indeed, the case back in the 1960's when I started programming computers. To a lesser extent, such was the case in the 1980's when the then new personal computers used MS DOS, an operating system that provided some of these services, but not all of them. Unix existed in the 1980's, but was used mostly on mainframe computers, not on personal computers. Nowadays, just about any personal computer can use the full power of Unix, thanks to the FreeBSD operating system.

Most programmers will never use int 80h in their code directly: Whatever programming language they use does it for them. The most popular programming language under Unix is C.

There is one programming language, however, which requires the programmer to use int 80h directly, namely the assembly language.

Assembly Language

What is assembly language, and why does it not provide the programmer with an indirect way of using int 80h?

To answer these questions, we need to understand that computers do not actually "speak" the various languages (such as the C language I mentioned). These languages were designed to make the programmer's job easier: They follow the rules of human languages, having a grammar and a syntax.

The code written in these languages, known as HLL (high-level languages) must either be compiled, i.e., translated to the machine language—the language of the computer, or they must be interpreted by another program.

The assembly language is quite different. Its instructions, or op codes, have a more-or-less one-on-one correspondence to the machine language. They, too, must be translated to the machine language, but instead of compiling, they are assembled.

The HLL code, too, is first translated into assembly language and then assembled, however, this translation is typically done by the compiler, not by the programmer. The compiler uses a techology known as optimization to create fast and lean assembly language code. Nevertheless, the compiler is a piece of computer software. Whenever it does not know whether a specific optimization might cause problems elsewhere in the code, it takes a cautious approach.

On the other hand, an experienced assembly language programmer, familiar with everything within the code can, and usually does, take a much bolder and more straightforward approach, cutting out everything that does not need to be there.

For that reason, assembly language programs are usually smaller and faster than corresponding HLL programs. I said "usually", because a novice assembly language programmer may not yet be aware of all the tricks and shortcuts he can take. But few people remain novice assembly language programmers. They either abandon assembly language very quickly, or they absolutely fall in love with it and become quite proficient very fast.

Why does not everyone program in assembly language?

There are several reasons why many (actually most) programmers use a HLL and not assembly language.

For one, it is like driving with a stick shift. You get more control over the car with the stick shift than with automatic transmission, but most drivers prefer the convenience of automatic transmission. Similarly, most programmers prefer the convenience of an HLL over the full control assembly language offers.

Secondly, there is a common myth among programmers that assembly language is very hard to use and that it takes much longer to code the same program in assembly language than in a HLL. This, indeed, is just a myth: assembly language is certainly not easy, but then no programming language is. assembly language is not harder than any other language, it is just different. An experienced assembly language programmer can and does code as fast in assembly language as an experienced C programmer does in C. It is simply a matter of familiarity.

A third, and certainly valid, concern is portability. An assembly language program is written for a specific CPU and will only run on that CPU. In early days of Unix the system was run on many different **CPU**s. A C program could be ported to a different architecture with a relative ease.

On the other hand, all MS DOS computers were built with the Intel family of microprocessors, hence an assembly language program would run on them all. Thus, assembly language was much more popular among MS DOS programmers than among Unix programmers.

But times have changed. For better or worse, the absolute majority of computers in existence today are built with the Intel family of microprocessors. Thus, portability is much less of a concern.

Assembly Language and Unix

As more and more computer users are disenchanted with MS DOS/Windows based systems, they are moving toward Unix. FreeBSD is a particularly good choice in this regard. That means that many of the assembly language programmers who used to program exclusively in the MS DOS environment are migrating toward Unix.

But information on assembly language programming in the Unix environment is scarce and hard to come by. That is why Whiz Kid Technomagic has started this web site: To make the information available to others as we keep discovering it. Stay tuned for more and more information on assembly language programming under Unix, and specifically FreeBSD, on this web site.

Please visit our FreeBSD Assembly Language Tutorial:

• Preface
• 1. The Tools
  • 1.1. The Assembler
  • 1.2. The Linker
• 2. System Calls
  • 2.1. Default Calling Convention
  • 2.2. Alternate Calling Convention
  • 2.3. Which Convention Should You Use?
• 3. Call Numbers
  • 3.1. The syscalls file
• 4. Return Values
  • 4.1. Man Pages
  • 4.2. Where Are The Return Values?
  • 4.3. Where Is errno?
  • 4.4. Determining an Error Occured
• 5. Creating Portable Code
  • 5.1. Dealing With Function Numbers
  • 5.2. Dealing With Conventions
  • 5.3. Dealing With Other Portability Issues
  • 5.4. Using a Library
  • 5.5. Using an Include File
• 6. Our First Program
  • 6.1. Assembling the Code
    • 6.1.1 Installing NASM
• 7. Writing Unix Filters
• 8. Buffered Input and Output
  • 8.1. How To Unread a Character
• 9. Command Line Arguments
• 10. Unix Environment
  • 10.1. How To Find Environment Variables
  • 10.2. webvar
    • 10.2.1 CGI: A Quick Overview
• 11. Working with Files
  • 11.1. Finite State Machine
    • 11.1.1 The Final State
    • 11.1.2 The Output Counter
  • 11.2. Implementing FSM is Software
  • 11.3. Memory Mapped Files
• 12. Caveats
• Appendix A – Assembly Language Pearls
• Appendix B – BSD Style Copyright
• Appendix C – Acknowledgements
• Terms of use