Re: [OT] ABI vs. API
On Sun, Feb 08, 2004 at 01:49:03PM -0700, Monique Y. Herman wrote:
> On 2004-02-08, Alan Chandler penned:
> > On Sunday 08 February 2004 19:12, Monique Y. Herman wrote:
> >> On 2004-02-04, Colin Watson penned:
> >
> >> > An ABI is the interface to a library as seen by compiled code. To
> >> > figure out the ABI for the above, you need to know things like
> >> > which way round the bytes in an int go, how long a pointer is, and
> >> > where the arguments go on the stack when you're calling a function.
> >> > More complicated and library-specific ABIs include things like the
> >> > way elements in a struct are laid out.
> >>
> >> [snip]
> >>
> >> Let me reword this to make sure I "get" it.
> >>
> >> An API is a contract that the author of a set of methods (I'd call
> >> them libraries, but this seems to be an overloaded term) provides to
> >> the user of these methods. The contract defines the legal method
> >> signatures.
> >>
> >> An ABI could be the compiled implementation of an API. Even if the
> >> API doesn't change, the ABI will change if the author changes the
> >> implementation of a method.
> >>
> >
> > The way you express that is wrong - but that might because you don't
> > quite understand what you have said.
>
> Hrm.
>
> >
> > An API is defined in terms of a High Level Language (eg C or C++,
> > although it could be any formal computer language)
> >
> > An "implementation" of a set of methods is defined by convention to
> > mean how the author choses to achieve the contract he has made at the
> > interface, not a definition of the converted API into binary form. So
> > this might be the algorithm used to perform the function the interface
> > defines and there may be several ways of doing this without changing
> > the interface. The particular one chosen by the author is his
> > implementation.
>
> This is exactly why I said "could be" as opposed to "is."
>
>
> > Presuming one understands that any high level language (eg C or C++)
> > which is used to define the API may also be used to make the
> > "implementation". A compiler takes that language used in the
> > implementation and turns it into binary. Similarly the user of an API
> > also takes his high level code and turns it into binary. Where
> > therefore have a binary version of the interface (or contract) between
> > the two parts. This is the ABI
>
> I don't think my above statements contradict this. I didn't define the
> ABI above; I did give an example of its potential use.
>
> > It is important, because to actually work on a computer the binary has
> > to be right. It is possible that different compilers take the same
> > language and turn it into different binary forms. This could lead to
> > problems. On the other hand, it is also possible for two different
> > languages to be used to write the implementation and the using code
> > such that the two compilers produce a compatible interface.
>
> Yes, although the latter would probably be non-trivial.
>
Actually usually this is quite easy since parameter, byte order,
variable alignment, etc. are quite standard on each platform. You do
need to be careful though with object oriented languages function name
mangling (such as in c++) though.
For example if you look at most high level math libraries they are
almost exclusively written in fortran but can be used directly in c.
> --
> monique
>
>
> --
> To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
> +++++++++++++++++++++++++++++++++++++++++++
> This Mail Was Scanned By Mail-seCure System
> at the Tel-Aviv University CC.
>
Reply to: