Yeah the big question is what’s gonna happen to the project after Linus…
you got it pretty much right. An ABI, depending on the context, could include just the app/OS interface or also the across-apps, across-apps-modules interface too. Things like calling convention, register usage, stack usage, etc.
when you distribute compiled libraries, you want clients to know how to invoke your functions and know how to retrieve your returned values. That’s part of the ABI too.
The ABI also defines the type translation from the language (say, C) to asm undertood by a processor (say riscv64g) so, you map types. Following that example, you may instruct the assembler and linker to use abi “lp64” that maps longs and pointers to 64 bits, and integers (int) to 32 bits. This abi also emulates floating point operations (n the other hand, lp64d would make use of dedicated hardware for “double precision” floats)
Yeah the big question is what’s gonna happen to the project after Linus…
you got it pretty much right. An ABI, depending on the context, could include just the app/OS interface or also the across-apps, across-apps-modules interface too. Things like calling convention, register usage, stack usage, etc.
when you distribute compiled libraries, you want clients to know how to invoke your functions and know how to retrieve your returned values. That’s part of the ABI too.
The ABI also defines the type translation from the language (say, C) to asm undertood by a processor (say riscv64g) so, you map types. Following that example, you may instruct the assembler and linker to use abi “lp64” that maps longs and pointers to 64 bits, and integers (int) to 32 bits. This abi also emulates floating point operations (n the other hand, lp64d would make use of dedicated hardware for “double precision” floats)