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