> I am building an Ada compiler as a hobby project. [...] native code > for various platforms and architectures, but to help with > bootstrapping, I also want it to be able to generate portable > C++11/POSIX code. This means I have to think about the difference > between API and ABI on POSIX platforms.
Well, if you want to generate C++ code and machine code for the same platform, then, yes, you will need to know how the C++ API maps into the underlying ABI. > As I see it, there are three levels of interface definition to consider: > 1. The API level, [...] > 2. The Pure-C level. [...] I don't see why this one is relevant. It exists, to the extent that it _does_ exist, only as an intermediate step during the conversion of API level 1 code to machine code. As you point out, it may not even be C. > 3. The ABI level. [...] Documents like the System V ABI describe how > Pure-C is translated to machine code calls. I thought they worked more at the level-1 API level: "a struct timeval looks like this in memory..." without any specification of what it looks like at the (as you say, largely fictional) pure-C level. > I am interested in an Interface Description Language that can be used > to: > a. Define the source-level API in a way that is detached from the > C language. This can be done, but only by attaching it to some other language instead. It doesn't even make sense to talk about an API without it being an API for some specific language; an API is an Application _Programming_ Interface, and you can't program without programming in some language. > c. Define data flow better than C allows: The struct stat* > argument to stat() is only meant to move data out of the > function. The pathname pointer isn't captured by the function > call. Doesn't the restrict qualifier get you at least part of this? > d. Describe how the API level gets translated to the Pure-C level > or similar. Why bother with this? The Pure-C level is often fictional and doesn't really matter anyway; for example, I can't see that it matters whether (for example) time_t is int, long, or __builtin_time_t; what matters is (a) what the API code looks like and (b) what it turns into in terms of bits in memory, registers, and syscall traps, and that can be described without needing to refer to any pure-C level anything. It sounds to me as though you want an ABI description language, not an API description language. A C - or C++, or any other language except Ada - API is of minimal value for you, except (a) to the extent that an ABI can be inferred from it or (b) to the extent that you are generating code in that "other language". Indeed, one could argue that an ABI is, essentially, an API for the machine-code level. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B