Compiled components need matching conventions
Separately compiled functions need agreement on parameter locations, return values, preserved registers and stack layout. An ABI can also specify object files, relocation and debugging information so tools produce interoperable components.
An API commonly describes a source-level interface; an ABI constrains compiled representations and transfers. Matching names and source declarations do not repair disagreement about where argument bits are actually placed.
References: [1]
Checking calling rules and data layout
The RISC-V integer convention uses a0–a7 for arguments, with the first two also returning values, and identifies preserved registers. Such software roles differ from which registers instructions may address; using x2 as a stack pointer is a convention.
ILP32 uses 4-byte int, long and pointers. Under LP64, int remains 4 bytes while long and pointers use 8. Member alignment and padding also affect structures, so type names alone do not determine binary layout.
Compatibility spans more than one layer
One ISA can support different ABIs, including different floating-point argument conventions. Named conventions and file flags describe those choices; linker checks do not automatically reconcile arbitrary mismatches.
ABI stability helps retain compiled compatibility without ensuring every library exists or every implementation is correct. Execution also depends on extensions, operating services, loaders and dependencies. Source portability through recompilation differs from directly running an existing binary.