From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 border2.nntp.dca3.giganews.com!backlog4.nntp.dca3.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!newspeer1.nac.net!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!feeds.phibee-telecom.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>
Newsgroups: comp.lang.ada
Subject: Re: Your wish list for Ada 202X
Date: Tue, 29 Apr 2014 17:10:28 +0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <ljome4$6j9$1@dont-email.me>
References: <7f1c01c5-3563-4b94-9831-152dbbf2ecdc@googlegroups.com>
 <206rutb9pqak$.11a3dufqvmrm4.dlg@40tude.net>
 <ea073fca-c607-476c-8c0b-81e2da1686b1@googlegroups.com>
 <lgvfga$bs7$1@loke.gir.dk> <ljocqj$rku$1@loke.gir.dk>
Injection-Date: Tue, 29 Apr 2014 17:10:28 +0000 (UTC)
Injection-Info: mx05.eternal-september.org;
 posting-host="e458ff8b81bc0c159989eb0e36c6e372";
 logging-data="6761"; mail-complaints-to="abuse@eternal-september.org";
 posting-account="U2FsdGVkX1+baa4PMztKfFDs41szeQRT6fTe/s34+xQ="
User-Agent: slrn/0.9.8.1 (VMS/Multinet)
Cancel-Lock: sha1:Ckg0MgDq3NLVW270rpBcGGuTgtU=
X-Original-Bytes: 2550
Xref: number.nntp.dca.giganews.com comp.lang.ada:186166
Date: 2014-04-29T17:10:28+00:00
List-Id: <comp.lang.ada>

On 2014-04-29, Tero Koskinen <tero.koskinen@iki.fi> wrote:
>
> Not sure have it been proposed anywhere, but a common ABI (application
> binary interface) for the most popular platforms (32-bit ARM Linux,
> 64-bit x86_64/amd64 Linux, 32-bit i386 Windows, 64-bit x86_64/amd64
> Windows) would be nice. This way I could use binary libraries generated
> by one Ada compiler (version) with another Ada compiler (version)
> without providing full sources (or recompilation).
>

That is simply not possible.

Your list above includes different architectures (ARM and x86) with
totally different instruction sets. The only way to support both
architectures in the way you want would be fat object modules or
fat libraries which contain both versions of a object module and
that doesn't even address the issues below.

However, even if you restrict yourself to x86/x86_64 then how do you
handle the 32 bit versus 64 bit pointer size issue ? Do you only
generate code for 32 bit x86 ?

However, even if you restrict yourself to 32 bit x86 then those object
modules will still have operating system specific components to them.

How do you handle architecture/operating system specific issues such as
exceptions ?

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world