--- created_at: '2016-08-21T14:09:15.000Z' title: Int 80h (2001) url: http://www.int80h.org author: joubert points: 63 story_text: comment_text: num_comments: 51 story_id: story_title: story_url: parent_id: created_at_i: 1471788555 _tags: - story - author_joubert - story_12330970 objectID: '12330970' year: 2001 --- [Source](http://www.int80h.org "Permalink to int80h.org -- Unix Assembly Language Programming") # 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_**][1] 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_**][2]. 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_**][2] 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_**][2] 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_**][1] 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_**][2], on this web site. Please visit our [FreeBSD Assembly Language Tutorial][3]: * [Preface][4] * [1\. The Tools][5] * [1.1. The Assembler][6] * [1.2. The Linker][7] * [2\. System Calls][8] * [2.1. Default Calling Convention][9] * [2.2. Alternate Calling Convention][10] * [2.3. Which Convention Should You Use?][11] * [3\. Call Numbers][12] * [3.1. The syscalls file][13] * [4\. Return Values][14] * [4.1. Man Pages][15] * [4.2. Where Are The Return Values?][16] * [4.3. Where Is `errno`?][17] * [4.4. Determining an Error Occured][18] * [5\. Creating Portable Code][19] * [5.1. Dealing With Function Numbers][20] * [5.2. Dealing With Conventions][21] * [5.3. Dealing With Other Portability Issues][22] * [5.4. Using a Library][23] * [5.5. Using an Include File][24] * [6\. Our First Program][25] * [6.1. Assembling the Code][26] * [6.1.1 Installing NASM][27] * [7\. Writing Unix Filters][28] * [8\. Buffered Input and Output][29] * [8.1. How To Unread a Character][30] * [9\. Command Line Arguments][31] * [10\. Unix Environment][32] * [10.1. How To Find Environment Variables][33] * [10.2. `webvar`][34] * [10.2.1 CGI: A Quick Overview][35] * [11\. Working with Files][36] * [11.1. Finite State Machine][37] * [11.1.1 The Final State][38] * [11.1.2 The Output Counter][39] * [11.2. Implementing FSM is Software][40] * [11.3. Memory Mapped Files][41] * [12\. Caveats][42] * [Appendix A – Assembly Language Pearls][43] * [Appendix B – BSD Style Copyright][44] * [Appendix C – Acknowledgements][45] * [Terms of use][46] [1]: http://www.whizkidtech.redprince.net/ [2]: http://www.FreeBSD.org/ [3]: http://www.int80h.org/bsdasm/ [4]: http://www.int80h.org/bsdasm/#intro [5]: http://www.int80h.org/bsdasm/#the-tools [6]: http://www.int80h.org/bsdasm/#the-assembler [7]: http://www.int80h.org/bsdasm/#the-linker [8]: http://www.int80h.org/bsdasm/#system-calls [9]: http://www.int80h.org/bsdasm/#default-calling-convention [10]: http://www.int80h.org/bsdasm/#alternate-calling-convention [11]: http://www.int80h.org/bsdasm/#use-geneva [12]: http://www.int80h.org/bsdasm/#call-numbers [13]: http://www.int80h.org/bsdasm/#the-syscalls-file [14]: http://www.int80h.org/bsdasm/#return-values [15]: http://www.int80h.org/bsdasm/#man-pages [16]: http://www.int80h.org/bsdasm/#where-return-values [17]: http://www.int80h.org/bsdasm/#where-errno [18]: http://www.int80h.org/bsdasm/#how-to-know-error [19]: http://www.int80h.org/bsdasm/#portable-code [20]: http://www.int80h.org/bsdasm/#deal-with-function-numbers [21]: http://www.int80h.org/bsdasm/#deal-with-geneva [22]: http://www.int80h.org/bsdasm/#deal-with-other-portability [23]: http://www.int80h.org/bsdasm/#portable-library [24]: http://www.int80h.org/bsdasm/#portable-include [25]: http://www.int80h.org/bsdasm/#first-program [26]: http://www.int80h.org/bsdasm/#assemble-1 [27]: http://www.int80h.org/bsdasm/#get-nasm [28]: http://www.int80h.org/bsdasm/#unix-filters [29]: http://www.int80h.org/bsdasm/#buffered-io [30]: http://www.int80h.org/bsdasm/#ungetc [31]: http://www.int80h.org/bsdasm/#command-line [32]: http://www.int80h.org/bsdasm/#environment [33]: http://www.int80h.org/bsdasm/#find-environment [34]: http://www.int80h.org/bsdasm/#webvar [35]: http://www.int80h.org/bsdasm/#cgi [36]: http://www.int80h.org/bsdasm/#files [37]: http://www.int80h.org/bsdasm/#finite-state-machine [38]: http://www.int80h.org/bsdasm/#final-state [39]: http://www.int80h.org/bsdasm/#tuc-counter [40]: http://www.int80h.org/bsdasm/#software-fsm [41]: http://www.int80h.org/bsdasm/#memory-mapped-files [42]: http://www.int80h.org/bsdasm/#caveats [43]: http://www.int80h.org/bsdasm/#pearls [44]: http://www.int80h.org/bsdasm/#bsd-style-copyright [45]: http://www.int80h.org/bsdasm/#acknowledgements [46]: http://whizkidtech.redprince.net/fancybald/