Why are systemcalls used in assembly programming?

Question

In my quest to understand what happens in the lowest level in a computer, I recently found out something so that I can start coding in assembly: https://0xax.github.io/asm_1/

    section .data
    msg db      "hello, world!"
section .text
    global _start
_start:
    mov     rax, 1
    mov     rdi, 1
    mov     rsi, msg
    mov     rdx, 13
    syscall
    mov    rax, 60
    mov    rdi, 0
    syscall

But what I see here is that there are syscalls being made and we are using an ABI. What I don't understand is why are there syscalls in assembly. What I know is that assembly to machine code more of a transtions - changing the opcodes to their binary equivalent etc.

So what I want to know is why are we making systemcalls and is there a way in which we can implement this in purely assembly instructions from the x86_64 ISA without using syscalls (hence maybe writing our own printing function.)

Answer 1

It is common for beginners to believe that Assembly is some kind of magic esoteric discipline that allows manipulating the fabric of reality itself.
When the disciple will be strong/knowledgeable/pure/sacred enough it will be able to master the hard, obscure, incomprehensible art of the assembly language.

But it is not.
Assembly is easy, very easy (In my opinion it is the lack of a type system make it unsuitable for daily programming, not its form). Much more easy than, say, C - that require hundred of carefully crafted pages of standards.

While it is true that you could potentially access the hardware directly in assembly (you can do this in every language given a small set of functions that reificates the architecture) this doesn't mean that 1) you actually can 2) it actually makes sense.

Point one is due to security reasons.
All modern processors allow the first to come to set an harness for the second to come, this translates to the OS setting a security perimeter for any application.
If this were not the case any code going rogue will make your OS unusable (what if they set you HD in an ATAPI locked state with a random password?).
So you have to ask the OS to do things on your behalf so that it can ensure you are not doing what you should not.

Point two is due to practical considerations.
You surely know that there a vast number hardware vendors, their devices usually follow some industry standard (but they could not) and these standards are not immediate to program.
Reading a file on an external SATA disk connected through a USB box, for example, require the knowledge of PCI(e), PCI(e) MSI, IOAPIC/APIC routeing, IDT, protected mode, IO mapping, XHCI, DMA, SCSI/ATAPI.
Each of this can require a book on itself.
Then you plug in a different device and that's a mostly different set of standards/technology to learn and master.
There is a bit of esoterism here, getting a full knowledge is hard because the resources are not always publicly available.
That's why the OS is there again to act on behalf of you - it will abstract the reading of a file into "opening a symbolic name" and "reading from a file descriptor".

All this is the concept of system calls.
It is not related to assembly at all but to the daily use of an operating system.

If you are interested in how the OS performs the system call, the Linux source code is a wonderful resource (an introductory book may be mandatory as OS are complex pieces of software).
If you want to know how a program interacts with an OS, looking at compilers output, runtime library, the ELF file format and its features, will shed some light.
If you want to program the bare metal then making a bootloader or a DOS program is a good place to start because is a mix between already crafted services and an environment where you are free to access the hardware.
Studying the chipset datasheets, particularly the bus topologies, technologies and connections, will help greatly (see for example this answer of mine which is not totally correct in its context but gives a list of bus technologies).
If you want to make a firmware then that's the same as making a bootloader except that since you are going to initialized and configure the hardware first you need a specific knowledge of a motherboard model.

And of course, as harold enlighted you: syscall is in the x86-64 ISA.

Answer 2

Simple overview:

System calls are the main way application running in user mode communicate with the kernel. One of the most important functions of an Operating Systems is to provide management of the system hardware. A "normal" application usually can't just access hardware resources at it's whim. It needs to go through the Operating System. It is the one responsible for managing multiple applications accessing the same device, ensuring correct access and providing security.

That's why an application will always need to communicate with the Operating System. The mechanism to communicate with the OS must be language-agnostic. That's what system calls are.