
Int 80h (2001) - joubert
http://www.int80h.org
======
nneonneo
Per the Internet Archive, this page is _at least_ fifteen years old - it
looked like this as of the first snapshot taken on February 1, 2001
([https://web.archive.org/web/20010201152900/http://int80h.org...](https://web.archive.org/web/20010201152900/http://int80h.org/)).
A lot has changed in computing since then.

ARM became dominant in mobile computing, which was barely a glimmer back in
2001. x86-64 became commonplace. Just targeting Intel and ARM processors now
necessitates writing code for four architectures: x86, x86-64, AArch32 and
AArch64 for a full range of compatibility.

While MS-DOS syscall numbers were documented and often _required_ assembly to
use, the opposite is true on modern Windows - Windows system call numbers are
undocumented and change from release to release, requiring programmers to link
against Kernel32.dll or equivalent to stably call into the OS.

Compiler technology has advanced significantly, and processor manufacturers
now often optimize towards patterns employed by compilers rather than by
humans (case-in-point: the x86 "loop" instruction, while extremely convenient
for handwritten code, is significantly less performant than a cmp-jmp loop).

Code has gotten more and more complex. Whether this is a good thing or bad,
the reality is that hundreds of millions of lines of assembly would be
required to replicate complex modern programs like web browsers - projects of
that scale will always require powerful HLLs to manage abstraction, something
that assembly does not and cannot provide on its own.

View this page as what it is - a historical artifact. Although assembly
programming definitely still has its uses, the arguments this page makes in
favor of it are largely no longer relevant.

~~~
saynsedit
Performant is not a word. Use a word more specific to your meaning, perhaps
"efficient" in this context.

~~~
ryandrake
I basically cringe and stop taking an author seriously when they use the non-
word "performant", but I've kind of given up pointing it out. Brother, we're
losing the fight to people who think it's perfectly cromulent to embetter the
language by innoventing their own words.

~~~
galdosdi
Where do you think language comes from anyway? If we'd adopted prescriptivist
ideas like this early enough, we'd still be grunting and pointing

~~~
emn13
<\--- hrugh.

------
mediocrejoker
> 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. [...] 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.

I don't really understand this argument. If a few lines of c can generate
dozens of lines of assembly, how can it not be faster to have the compiler
write assembly for you?

~~~
gens
Something like "(x _3+(y /20)_5)" will generate a few lines of assembly (about
3 to 5 in this case, assuming registers are pre-loaded). But usually no, there
won't be much more code. For example "while(1){..." equals just one
instruction, and "for(x=10, x<0, x--){..." is 2-3 instructions.

edit: idk how to put a asterisk up there in the example above

I have no idea where people get the idea that one line of C equals 10 lines of
asm.

PS Assembly is not hard at all, and is good to understand/read assembly when
coding C. The only thing is that it is a bit rough to start coding in it (no
good tutorials is one of the two-three difficulties).

~~~
mschuster91
> I have no idea where people get the idea that one line of C equals 10 lines
> of asm.

Because coding in asm takes more than just the raw instructions.

x86 doesn't have many registers so you're shifting around stuff across
registers and memory all the time, not to mention stack setup/teardown and the
error checking (e.g. div0, overflow) you are supposed to do after operations.

~~~
gens
C doesn't check for overflows..

I also disagree with "shifting around stuff across registers and memory all
the time". An "average" function doesn't really have all that many variables
and x86 has 8 GP registers (16 on amd64). You don't even have to declare
variables, you just take a register (and/or a location in memory) and use it
as you wish.

I'm now sitting here thinking what can be done in C that would end up being a
lot of instructions, and i can't think of anything. Going over an array does
not, neither does recursion (recursion is just syntactic sugar in the end).
What else.. i can't think of anything. Macros ? But macros are cheating in
this comparison (not to mention that the flat assembler has actual macros,
that are extremely powerful)

~~~
userbinator
_C doesn 't check for overflows.._

This is one of the things where (x86) Asm is definitely easier: divide
overflows naturally cause an exception which will get handled automatically,
and add/subtract/multiply overflows can be checked with one extra (JO or JC)
instruction. In C, this is all undefined behaviour.

 _I 'm now sitting here thinking what can be done in C that would end up being
a lot of instructions, and i can't think of anything._

Crypto algorithms come to mind, but like you said, macros can take care of
that easily... and on this page is an AES-256 CFB implementation in Asm that
is around the same size of source as others in C (but much smaller binary):

[http://reimagery.com/fsfd/encrypt.htm](http://reimagery.com/fsfd/encrypt.htm)

------
aurelian15
Note that for modern x86 processors there are the fast systemcall instructions
syscall/sysret (AMD64) and the older sysenter/sysexit. In contrast to int 80h,
those instructions do not bear the full interrupt overhead. I couldn't find
this info anywhere on the website.

See e.g. [1] for a more comprehensive overview concerning the handling of
system calls on Linux.

[1] [http://blog.packagecloud.io/eng/2016/04/05/the-definitive-
gu...](http://blog.packagecloud.io/eng/2016/04/05/the-definitive-guide-to-
linux-system-calls/)

~~~
joshumax
For those interested, Linux has a remarkably interesting way to determine
whether to use the modern sysenter/sysexit routines or the ancient 0x80
interrupt vector. [http://www.trilithium.com/johan/2005/08/linux-
gate/](http://www.trilithium.com/johan/2005/08/linux-gate/) discuses the
system quite nicely.

------
drallison
Actually, Int 80h is a op-code in x86 assembly language inherited from the
Intel 8008 and 8080 8-bit processors. The post announces a Free BSD assembly
language tutorial for the x86.

------
cylinder714
Please, next time add a description to the title, like " \- BSD assembly
language".

------
james_a_craig
"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."

I'm guessing this article is somewhat out of date. The systems where
performance matters most - those most likely to be constrained in some way,
where coding in assembly would yield the most benefit - are mobile platforms,
which invariably means ARM not x86.

------
asveikau
I remember coming across this article back then, in 2001, or maybe it was even
2000. I found it fascinating at the time and wrote lots of little programs
that talk to the syscall interface directly. It was a good learning
experience.

I think the emphasis on the 0x80 interrupt was to draw parallels to the old
DOS calls - int 21h - and make a point that nothing technically stops you from
doing the equivalent on Unixy system. (A few years after this the sysenter
thing came along and so now int 80h is a legacy path..)

Sadly a lost art, all of this. Talking about this is a great way to get blank
stares from many people.

------
ezequiel-garzon
Sorry to rant for the nth time about this, but why does Chrome offer you to
make this wonderful, CSS-free, content-oriented document "mobile friendly"?
That is, why ask for permission? Can't browsers render documents as they see
fit when there are no CSS rules? As far as I can tell, the only difference
once you accept is more generous margins as well as a gray background for
<code> elements... I'd say it _does_ look more readable, maybe even on the
desktop. Chrome, Firfox, IE, Safari, et al: be bold (or otherwise styled) with
CSS-free documents!

