A few facts about POSIX

How did we get there?

In the early days of computing, programmers could only dream of portability. All programs were written directly in machine code for each computer architecture they were intended to run on. Assembly languages with mnemonic names for each CPU instruction and other goodies made programmers' lives a little easier, but programs were still architecture-specific. Operating systems (OS) had not yet been invented, so a program not only controlled the entire computer system, it also had to initialize and manage the peripherals. In fact, such bare-metal programs implemented drivers for every device they used. And every time a program needed to run on hardware with a different architecture, it was literally rewritten to accommodate a difference in the CPU instruction set, memory layout, and so on.

This is exactly what happened with Unix, which was originally written in assembly language by Ken Thompson over 50 years ago. The first versions of Unix were written for the PDP-7 platform, and porting it to the PDP-11 meant rewriting the code. When Dennis Ritchie created the C programming language, and together they rewrote most of the Unix code in it, software portability suddenly became possible. There are two main reasons for this. First, the code written in a high-level programming language is platform-agnostic, because compilers translate it into the assembly language for a target architecture. This is even more important for target systems based on RISC CPUs, as they require writing significantly more assembly instructions than CISC CPU architecture. Even porting Unix to another platform was mostly a matter of adapting the architecture-dependent parts of the code. On the other hand, the operating system itself abstracts away all hardware specifics from a user program. Programmers don't have to implement multitasking, memory management, or drivers for different devices as they used to, because it's all part of the OS kernel and runs in the kernel address space. In contrast, user programs run in the user address space and access all of the features provided by the OS through the the system call interface. In Real-time OSes, such as Zephyr OS, it's slightly different, but the idea of memory isolation and protection for user programs is preserved. This leads to two conclusions:

• User programs become portable when they are written in a high-level programming language for a particular OS. Once both requirements are met, programs are compiled into instructions for a target CPU and linked with system functions provided by the libc and OS-specific libraries to access the underlying hardware.
• Portability is intended to be achieved at the source code level.