What does the following assembly code do?
int 0x80
The code line (string) "
int 0x80
"
instructs the assembler to produce the two machine code bytes CD 80 (in hexadecimal) [I didn't look up that now, I remember some intel x86 machine code by heart even if I'm not using much that since long], then the assembler will move to the next line, without the need (for the assembler) to do anything else in that regard, that's a pretty simple instruction from the assembler point of view.
What Intel says its processor does is written in Intel® 64 and IA-32 Architectures Software Developer’s Manual Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D, and 4
Other answers focused on what the processor is assumed to do after, but in regard to int 80h nowadays it likely depends on how the OS/distribution chose to support 32bit in 64bit (AMD64) architecture, the instruction (0f 05)syscall should be used instead to interact with 64bit unix OSs (For example for an overview of syscall in OpenBSD see the files that were generated by makesyscalls.sh
syscalls.master
handled by https://github.com/openbsd/src/blob/master/sys/sys/syscall_mi.h#L132, mostly reached by the syscall instruction (in x86 not opcode cd 80 but 0f 05) in syscall function in the c library
$ objdump-sub /usr/lib/libc.so.84.2 syscall
objdump -d --start-address=0x0000000000090430 --stop-address=$((0x0000000000090430+0x000000000000000d)) /usr/lib/libc.so.84.2
/usr/lib/libc.so.96.0: file format elf64-x86-64
Disassembly of section .text:
00000000000b26e0 <_thread_sys___syscall>:
b26e0: b8 c6 00 00 00 mov $0xc6,%eax
b26e5: 49 89 ca mov %rcx,%r10
b26e8: 0f 05 syscall ; Look THIS line
b26ea: 72 01 jb b26ed <_thread_sys___syscall+0xd>
b26ec: c3 retq
b26ed: 64 89 04 25 20 00 00 mov %eax,%fs:0x20
b26f4: 00
b26f5: 48 c7 c0 ff ff ff ff mov $0xffffffffffffffff,%rax
b26fc: c3 retq
Disassembly of section .plt:
Interrupts above 20h communicate with the operating system or firmware [e.g. BIOS(Basic Input Output System present in ~ROM) has INT 13h, INT 10h and other.. which now conflict without issues with CPU exceptions, DOS had its interrupt(s) (INT 21h as an API and INT 20h only to terminate a program), linux OS services kind of API to programs named in unix "system call" was originally chosen on int 80h as long as processors operated in 32bit mode, as well did other unices for x86 architecture as 386/BSD.
Such way to interface with the OS has a short opcode (no need to call far address... even though it can in some cases possibly be emulated by few other instructions (9C)pushf and call address specified at a memory location, however emulate the call would enter the execution with lower privileges as protection mode separate the privilege on which code is executed)
There are way less than 257 classes of hardware signals to handle as the INT instruction in theory permits as its natural hardware signal design (one more than 256 is because INT 03 has two possible opcodes, the obvious CD 03 and the special INT3 single byte opcode CC to facilitate the way hardware breakpoint was injected originally into 8088 CPU by 8259 PIC, the leftover by signal handling is suitable as a global API to across-context-call code in memory, as intel later documented.
see also