Application Binary Interface (ABI)

The calling convention is a core ABI rule that specifies how function calls are made at the machine level. It dictates:

• Register usage: Which CPU registers are used to pass arguments, hold return values, and must be preserved (callee-saved) across calls.
• Stack management: How arguments are pushed onto and cleaned from the call stack, and the alignment of stack frames.
• Return value handling: The mechanism for returning simple values, structs, or floating-point numbers.

Examples include the System V AMD64 ABI used on Linux and macOS, and the Microsoft x64 calling convention on Windows. For NPUs, a vendor-specific calling convention defines how kernels are launched and how data is passed between the host CPU and the accelerator.

This component defines how fundamental data types are represented in memory and registers, ensuring consistent interpretation. Key aspects include:

• Size and layout: The exact byte size of types like int, long, double, and complex structures.
• Alignment requirements: Rules that data addresses must be multiples of certain values (e.g., a 64-bit integer aligned to an 8-byte boundary) for optimal memory access. Misalignment can cause severe performance penalties or crashes on some architectures.
• Endianness: The byte order (big-endian or little-endian) for multi-byte values.
• Padding: The insertion of unused bytes within structures to satisfy alignment rules.

For NPU programming, this extends to defining the layout of tensors in memory (e.g., NCHW vs. NHWC format) and the alignment of data buffers for direct memory access (DMA).

The ABI specifies the standard object file format used for compiled code, libraries, and executables. This format defines the structure for:

• Sections: Segments like .text (code), .data (initialized data), .bss (uninitialized data), and symbol tables.
• Relocation records: Instructions for the linker on how to patch addresses when combining multiple object files.
• Debugging information: The format for embedding source code mappings and variable data.

The dominant format for Unix-like systems is the Executable and Linkable Format (ELF). A stable ABI ensures that object files and shared libraries (.so files on Linux, .dylib on macOS) produced by one compiler can be linked with those from another. For NPU kernels, the object format contains the binary code and metadata for the target accelerator.

Name mangling (or name decoration) is a compiler technique that encodes function and variable names with additional type and namespace information into a single unique string (symbol) in the object file. This enables:

• Function overloading: Distinguishing between functions with the same name but different parameter types (e.g., print(int) vs. print(float)).
• Namespace support: Encoding C++ namespaces and class hierarchies.
• Type-safe linking: Preventing accidental linking of mismatched function signatures.

Mangling schemes are compiler and ABI-specific. The Itanium C++ ABI (used by GCC and Clang) and the Microsoft Visual C++ mangling schemes are incompatible. This is a critical consideration when linking C++ libraries across compiler toolchains.

The ABI defines the mechanism for exception handling and the interface to language runtime libraries. This includes:

• Unwinding tables: Data structures that allow the stack to be unwound when an exception is thrown, calling destructors for local objects (in C++) and finding the appropriate catch block.
• Runtime library integration: How programs interact with standard libraries (like libc or libc++) for operations such as dynamic memory allocation (malloc/free), thread-local storage, and startup/teardown routines.
• Personality routines: Specific functions that frame the exception handling logic for a given programming language.

For systems programming and high-performance computing, understanding these low-level details is essential for debugging complex crashes and writing interoperable code.

While sometimes distinguished from the pure compiler-level ABI, the system call interface is a crucial low-level contract. It defines how user-space programs request services from the operating system kernel, including:

• System call numbers: The unique identifier for each kernel operation (e.g., read, write, mmap).
• Argument passing: The registers used to pass parameters to the kernel.
• Return and error conventions: How success values and error codes are returned.

This interface is architecture and OS-specific (e.g., Linux on x86_64 vs. ARM64). For NPU deployment, system calls are used to map device memory, schedule DMA transfers, and interact with the driver managing the accelerator hardware.

The Executable and Linkable Format (ELF) is the standard binary file format used by most Unix-like operating systems (Linux, BSD). It is the concrete realization of many ABI specifications. An ELF file defines how code and data are laid out in memory and contains the metadata needed for dynamic linking.

• Structure: Includes headers, program headers (for execution), and section headers (for linking).
• Role in ABI: Specifies the on-disk representation of relocation records, symbol tables, and dynamic linking information that the runtime linker uses, as dictated by the platform's ABI.

A Hardware Abstraction Layer (HAL) is a software layer that provides a uniform, standardized interface for an operating system or application to interact with hardware, insulating it from device-specific details. It sits above the ABI.

• Relationship to ABI: While the ABI defines how software components interact at the binary level (e.g., function calls), the HAL provides a higher-level, often source-level, API for hardware operations (e.g., read_sensor()). The HAL implementation itself must adhere to the system's ABI when it calls into the kernel or drivers.

Ahead-of-Time Compilation (AOT) is a compilation strategy where source code or an intermediate representation is fully compiled into a native machine binary before execution. This is in contrast to Just-in-Time (JIT) compilation.

• ABI Dependency: AOT-compiled binaries are statically linked to a specific ABI. The compiler must know the exact calling convention, register usage rules, and system call numbers defined by the target ABI to generate correct machine code.
• Use Case: Essential for deployment on embedded systems, mobile devices, and environments where JIT compilation overhead is unacceptable.

Just-in-Time Compilation (JIT) is a compilation strategy where code (often bytecode or an intermediate representation) is compiled into native machine code during program execution, immediately before it is needed.

• ABI Conformance: The JIT compiler must generate code that strictly adheres to the host platform's ABI. This includes setting up stack frames, preserving caller-saved and callee-saved registers, and making system calls correctly.
• Dynamic Adaptation: While JIT can optimize for the current CPU, the generated code's low-level interface is still constrained by the stable ABI to ensure it can call and be called by other system libraries.

Inter-Process Communication (IPC) refers to the mechanisms provided by an operating system for processes to exchange data and synchronize execution. Common methods include pipes, sockets, shared memory, and message queues.

• ABI's Role: The ABI defines the low-level system call interface used to invoke IPC mechanisms (e.g., the syscall number and argument passing for shmget or msgsnd). Furthermore, when data structures are passed via shared memory or messages, their in-memory layout (padding, byte order) must be consistent, which is also governed by the ABI's data representation rules.

Direct Memory Access (DMA) is a hardware feature that allows peripherals (like storage or network controllers) to read from and write to system memory directly, without continuous CPU intervention.

• ABI & System Integration: While DMA is a hardware capability, software configures it through memory-mapped I/O registers or commands. The driver software that manages DMA must:
  • Understand the system's physical-to-virtual memory mapping conventions.
  • Ensure cache coherency (which may involve architecture-specific instructions defined by the ABI).
  • Use correct memory barrier instructions to order accesses, as specified by the architecture's memory model, which is part of the broader system ABI.