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
There is one programming language, however, which requires the programmer to use
int 80h directly, namely the
assembly language, and why does it not provide the programmer with an indirect way of using
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.
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
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
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
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: