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.
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.
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 CPUs. 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.
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: