6 ms·

Int 80h (2001)

63 points by _zhqs 10y ago

cylinder714 10y ago
Please, next time add a description to the title, like " - BSD assembly language".
drallison 10y ago
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.
aurelian15 10y ago
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-guide-to-linux-system-calls/ http://blog.packagecloud.io/eng/2016/04/05/the-definitive-gu...
- joshumax 10y ago
  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.
- deleted 10y ago
  [deleted]
- yuhong 10y ago
  SYSCALL/SYSRET is my favorite one, since it does not change ESP/RSP: http://web.archive.org/web/20120615223202/http://www.x86-64.org/pipermail/discuss/2000-October/001009.html http://web.archive.org/web/20120615223202/http://www.x86-64.... What is even worse is that I think Intel made the mistake of checking for canonical addresses and GP#ing on the SYSRET instruction itself.
mediocrejoker 10y ago
> 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?
- wtetzner 10y ago
  Yes, and C isn't even particularly high level.
- robert_tweed 10y ago
  Macro assemblers. It would be a pain without macros.
- naner 10y ago
  Also when writing C you don't have to be 'an experienced assembly programmer' to write performant and portable code. That is one of the driving points of a HLL: you don't need to know as much minutiae to write good maintainable code. I understand getting into assembly for the purpose of learning or squeezing out that last bit of performance, but it isn't a general purpose programming language anymore and shouldn't be a default choice over a HLL for most applications.
- pavlov 10y ago
  Because programmers are not typists? Translating a thought into a programming concept usually takes more time than typing it out, even in assembly.
  - pcwalton 10y ago
    I dunno. I think by any measure being able to write "x / 3" will gain you productivity vs. "imul eax,2863311531; shr eax,1" (with the trip to the Hacker's Delight page necessary to look up the magic number).
james_a_craig 10y ago
"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.
nneonneo 10y ago
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.
- m0skit0 10y ago
  I think programming in assembly really teaches you how a computer work. That's its main benefit imho.
- _c_ 10y ago
  MS-DOS was written for only one processor. UNIX kernels could run on a variety of processors, including ARM; UNIX was a relative latecomer to x86. As for Windows kernels, both then and now, UNIX kernels are open source and do not deliberately obscure system calls. It's not unreasonable for someone to argue the benefits in writing programs for UNIX. "View this page as what it is..." It's one of the few pages written about UNIX assembly. That's how I view it. Years later it was put into The FreeBSD Handbook.
ezequiel-garzon 10y ago
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!
asveikau 10y ago
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.

Int 80h (2001)

63 points by _zhqs 10y ago

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

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.

aurelian15 10y ago

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-guide-to-linux-system-calls/ http://blog.packagecloud.io/eng/2016/04/05/the-definitive-gu...

joshumax 10y ago
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.
deleted 10y ago
[deleted]
yuhong 10y ago
SYSCALL/SYSRET is my favorite one, since it does not change ESP/RSP: http://web.archive.org/web/20120615223202/http://www.x86-64.org/pipermail/discuss/2000-October/001009.html http://web.archive.org/web/20120615223202/http://www.x86-64.... What is even worse is that I think Intel made the mistake of checking for canonical addresses and GP#ing on the SYSRET instruction itself.

mediocrejoker 10y ago

> 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?

wtetzner 10y ago
Yes, and C isn't even particularly high level.
robert_tweed 10y ago
Macro assemblers. It would be a pain without macros.
naner 10y ago
Also when writing C you don't have to be 'an experienced assembly programmer' to write performant and portable code. That is one of the driving points of a HLL: you don't need to know as much minutiae to write good maintainable code. I understand getting into assembly for the purpose of learning or squeezing out that last bit of performance, but it isn't a general purpose programming language anymore and shouldn't be a default choice over a HLL for most applications.
pavlov 10y ago
Because programmers are not typists? Translating a thought into a programming concept usually takes more time than typing it out, even in assembly.
- pcwalton 10y ago
  I dunno. I think by any measure being able to write "x / 3" will gain you productivity vs. "imul eax,2863311531; shr eax,1" (with the trip to the Hacker's Delight page necessary to look up the magic number).

james_a_craig 10y ago

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

nneonneo 10y ago

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.

m0skit0 10y ago
I think programming in assembly really teaches you how a computer work. That's its main benefit imho.
_c_ 10y ago
MS-DOS was written for only one processor. UNIX kernels could run on a variety of processors, including ARM; UNIX was a relative latecomer to x86. As for Windows kernels, both then and now, UNIX kernels are open source and do not deliberately obscure system calls. It's not unreasonable for someone to argue the benefits in writing programs for UNIX. "View this page as what it is..." It's one of the few pages written about UNIX assembly. That's how I view it. Years later it was put into The FreeBSD Handbook.

ezequiel-garzon 10y ago

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!

asveikau 10y ago

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.