Understanding the hardware of printf

Question

I was wondering if there was any resources available online that explains what happens with something, like printf of C, that explains what's going on in the very low level (BIOS/kernel calls)

Answer 1

A good exercise to do although it will be somewhat difficult would be to trace the call through the linux kernel. You can DL it at http://www.kernel.org/

Answer 2

Linux:

printf() ---> printf() in the C library ---> write() in C library ---> write() system call in kernel.

To understand the interface between user space and kernel space, you will need to have some knowledge of how system calls work.

To understand what is going on at the lowest levels, you will need to analyze the source code in the kernel.

The Linux system call quick reference (pdf link) may be useful as it identifies where in the kernel source you might begin looking.

Answer 3

This is very platform-specific. From a hardware perspective, the back-end implementation of printf() could be directed to a serial port, a non-serial LCD, etc. You're really asking two questions:

1. How does printf() interpret arguments and format string to generate correct output?

2. How does output get from printf() to your target device?

You must remember that an OS, kernel, and BIOS are not required for an application to function. Embedded apps typically have printf() and other IO routines write to a character ring buffer. An interrupt may then poll that buffer and manipulate output hardware (LCD, serial port, laser show, etc) to send the buffered output to the correct destination.

Answer 4

By definition, BIOS and kernel calls are platform-specific. What platform are you interested in? Several links to Linux-related information have already been posted.

Also note that printf may not even result in any BIOS or kernel calls, as your platform may not have a kernel or BIOS present (embedded systems are a good example of this).

Answer 5

Something like printf, or printf specifically? That is somewhat vague.

printf outputs to the stdout FILE* stream; what that is associated with is system dependent and can moreover be redirected to any other stream device for which the OS provides a suitable device driver. I work in embedded systems, and most often stdout is by default directed to a UART for serial I/O - often that is the only stream I/O device supported, and cannot be redirected. In a GUI OS for console mode applications, the output is 'drawn' graphically in the system defined terminal font to a window, in Windows for example this may involve GDI or DirectDraw calls, which in turn access the video hardware's device driver. On a modern desktop OS, console character output does not involve the BIOS at all other than perhaps initial bootstrapping.

So in short, there typically is a huge amount of software between a printf() call and the hardware upon which it is output.