Application Binary Interface (ABI)

The calling convention is a fundamental ABI rule that dictates how functions pass arguments, return values, and manage the stack and registers during a subroutine call. For NPU kernels, this defines how host CPU code invokes an accelerator kernel and how data pointers are passed.

• Key Aspects: Specifies which registers are caller-saved vs. callee-saved, the order of arguments (e.g., passed in registers R0-R3, then on the stack), and stack alignment requirements.
• NPU Relevance: A vendor's NPU driver and runtime enforce a specific calling convention for kernel launches. Mismatches between the compiler's expectation and the runtime's implementation cause catastrophic crashes.

This component specifies how data types (structs, unions, arrays) are arranged in memory, including byte ordering (endianness), alignment boundaries, and padding. Consistency is critical for data exchange between host CPU and NPU.

• Packing: Defines if struct members are packed tightly or aligned to natural boundaries (e.g., a 4-byte int aligned to a 4-byte address).
• Impact: An NPU kernel expecting a tightly packed struct of float values will read garbage data if the host compiler pads the struct differently. Vendor SDK header files define standard data types with explicit alignment attributes (e.g., __attribute__((aligned(16)))).

The ABI specifies the binary container format for compiled code and data, such as ELF (Executable and Linkable Format) or Mach-O. This format organizes the executable into sections (.text, .data, .rodata) and contains metadata for linking and loading.

• Sections: The .text section holds executable machine code (the NPU kernels), .data holds initialized global variables, and symbol tables (.symtab) map names to addresses.
• NPU Toolchains: Vendor-specific compilers (a key part of the vendor toolchain) generate object files in a format the NPU's loader and runtime can parse. The linker (guided by a linker script) combines these into a final binary image loadable by the vendor runtime.

For NPUs integrated into an OS-managed system, the ABI defines the mechanism for user-space code to request services from the kernel driver, such as memory allocation or kernel submission. This is often implemented via a Driver API.

• Mechanism: Typically involves issuing a specific software interrupt or using a special instruction (like SVC on ARM) that traps into the kernel. The driver then validates the request and communicates with the NPU hardware.
• Example: An application calls npucalloc() from the Vendor SDK, which internally makes a system call to the driver to allocate device-accessible memory, adhering to the defined ABI for parameter passing.

Name mangling (or decoration) is a compiler technique for encoding function and variable names with additional information (like argument types) into a single symbol string in the object file. This enables features like function overloading in C++ and ensures unique symbols for linking.

• ABI Role: The mangling scheme is part of the ABI. Different compilers (or versions) using different schemes cannot link objects together.
• NPU Development: When using a C++ Vendor SDK, the mangled kernel names in the host code must exactly match the symbols exported by the NPU-compiled kernel object. Mismatches result in "undefined symbol" linker errors.

This ABI component defines the mechanism for propagating runtime error conditions (exceptions) and for unwinding the call stack during error recovery or debugging. For NPU programming, this often relates to host-side error reporting from the accelerator.

• Frame Unwinding: Specifies how to walk back through the stack frames to find exception handlers, using unwind tables or specific frame pointer registers.
• NPU Context: If an NPU kernel encounters a hardware fault (e.g., illegal instruction), the vendor runtime must translate this into a host-side signal or exception that conforms to the host OS ABI, allowing the application to handle it gracefully.

A core component of an ABI that defines the low-level protocol for function calls. It specifies:

• Register usage: Which CPU registers are used to pass arguments and return values.
• Stack management: How the call stack is framed, who cleans up arguments (caller vs. callee).
• Preserved registers: Which register states must be saved and restored by the called function.

For NPUs, a separate kernel launching convention often exists within the vendor runtime, defining how kernel arguments are marshaled to the accelerator.

The Instruction Set Architecture defined by a hardware vendor for their specific processor or accelerator (e.g., an NPU). The ABI is built on top of the ISA. Key relationships:

• The ISA defines the raw instructions (e.g., VADD, TMMUL).
• The ABI defines how those instructions are organized into callable functions, how data is structured in memory for them, and how control is transferred.
• Compiler intrinsics map high-level functions to specific ISA instructions, adhering to the ABI's rules for parameter passing and register usage.

The Executable and Linkable Format (ELF) is the standard container for binaries, and its structure is dictated by the ABI.

• .text section: Contains the executable machine code (ISA instructions).
• .data & .bss sections: Hold initialized and uninitialized static data, with layout rules defined by the ABI.
• Relocation: The process where the linker adjusts symbolic addresses in the code (e.g., call printf) to absolute memory addresses. The ABI specifies the relocation types and formats the linker must use, which differ between architectures (e.g., RISC-V vs. ARM).

The ABI governs how code modules are combined, which is critical for using vendor libraries.

• Static Library (.a): Object code archived into a library. Linked at compile-time; the library code is copied directly into the final executable. Requires ABI compatibility at link time.
• Dynamic Library (.so / .dll): Linked at runtime. The executable contains PLT (Procedure Linkage Table) and GOT (Global Offset Table) entries, as defined by the ABI, to resolve function addresses when the program loads. This allows sharing a single vendor runtime library (e.g., libvx_runtime.so) among many applications.

A cross-compiler is essential for NPU development, generating code for a target NPU (e.g., ARM-based accelerator) on a different host machine (e.g., x86). The entire vendor toolchain (compiler, assembler, linker) must implement the target's ABI correctly.

• The compiler's code generator must emit instructions following the vendor ISA and the calling convention.
• The linker must understand the target's ELF format and relocation types.
• The vendor SDK provides these tools, headers, and libraries that are all ABI-compliant for the specific hardware.

While the ABI is a binary contract, a HAL is a source-level interface. The HAL provides a uniform API to hardware-specific features, but its implementation is where ABI details are handled.

• A vendor's HAL driver will contain inline assembly or compiler intrinsics that conform to the NPU's ABI for low-level register access.
• It translates high-level API calls (e.g., hal_memcpy_to_device) into sequences of commands that respect the driver's Driver API, which itself has an ABI for system calls or kernel-mode interactions.