Execute system calls directly

I don't have that book to check, but I assuming its using the normal meaning of system calls, then a system call is a call into the kernel to perform some operation the hardware considers privileged, or is unaware of. This is used to enforce permissions, etc. on the system. So you need to make a system call to (among many other things):

• read from a file (the kernel must check that the permissions allow you to read from said file, and then the kernel carries out the actual instructions to the disk to read the file)
• signal a process (processes do not exist as far as the hardware is concerned, they are an abstraction provided by the kernel, etc.)
• obtain additional memory (the kernel must make sure you don't exceed the ulimit, make sure two processes don't claim the same RAM, etc.)

Math is not one of those things. Typically, it requires no intervention from the kernel.

For most of the system calls with man pages in section 2, the man pages actually describe the C library wrappers. The exceptions are usually mentioned explicitly, like gettid that @Sergei Kurenkov refer's to in their answer:

NOTES Glibc does not provide a wrapper for this system call; call it using syscall(2).

Similarly with pivot_root (which isn't that useful for general applications), tgkill (which performs the low-level function of pthread_kill). Then there's readdir, where the actual system call is somewhat different from the library function:

DESCRIPTION This is not the function you are interested in. Look at readdir(3) for the POSIX conforming C library interface. This page documents the bare kernel system call interface, which is superseded by getdents(2).

Note that there has to be some sort of wrapper. Function calls are made using the C calling conventions, which is different from the calling convention of the kernel interface. Usual function calls are made with the call assembly instruction (or similar), kernel calls with syscall or int 0x80 (and that's not counting stuff like gettimeofday or getpid in the vdso). The compiler doesn't (need to) know which function calls map to an an actual kernel call.

Even with the "usual" system calls, the C library wrapper acts slightly differently from the bare system call: The system calls return the error codes as varying negative values (if you look at the Linux kernel code, you'll see a lot of returns like return -EPERM;). The C library wrapper turns all such return values to -1, and moves the actual error code to errno.