This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
Toon Knapen wrote:
> Greg Lindahl wrote:
>> mostly talks about why we need an ABI, who wins and loses as a result
>> of having one, and the pieces that could be in it. Please give it a
The presentation ignores the issue of instruction set. Even within the
we have IA-32, EMT 64, and AMD-64.
Beyond that, there are IA-64 and PowerPC clusters with interesting
market share, plus the
odd PlayStation MIPS machines.
Beyond that, we have the situation where toolchains have incompatible
calling standards, even for the same architecture. Shall we standardize
on GCC? On
IFC? (I note EKOPATH is GNU compatible.)
Beyond that, an ABI stifles performance. The compiler (in principle at
could do interprocedural optimizations between the application and MPI
Even just shipping code as binary forces the vendor into poorly
optimized code, in order
to assure functionality on different models of machines. RPMs are not
with -O3 -pipe -fomit-frame-pointer, for example. And what about -g?
Take a look
at the way gentoo systems regularly trounce other distributions in
Optimization makes a difference.
Use the source.