Re: Language-neutral interface specifications (research)

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> 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		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B