From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25605 invoked by alias); 4 Oct 2011 00:47:38 -0000 Received: (qmail 25594 invoked by uid 22791); 4 Oct 2011 00:47:37 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,TW_JL X-Spam-Check-By: sourceware.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 04 Oct 2011 00:47:24 +0000 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 27C9C1B4022; Tue, 4 Oct 2011 00:47:22 +0000 (UTC) From: Mike Frysinger To: Michael LIAO Subject: Re: new triplet for x32 psABI? Date: Tue, 04 Oct 2011 00:47:00 -0000 User-Agent: KMail/1.13.7 (Linux/3.1.0-rc4; KDE/4.6.5; x86_64; ; ) Cc: autoconf@gnu.org, gcc@gcc.gnu.org, x32-abi@googlegroups.com, config-patches@gnu.org References: <201110031903.43037.vapier@gentoo.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2503549.NPydE5rOPy"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201110032046.49204.vapier@gentoo.org> Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-10/txt/msg00032.txt.bz2 --nextPart2503549.NPydE5rOPy Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-length: 2134 On Monday, October 03, 2011 19:47:57 Michael LIAO wrote: > On Mon, Oct 3, 2011 at 4:03 PM, Mike Frysinger wrote: > > On Monday, October 03, 2011 18:57:28 Michael LIAO wrote: > >> Most examples would be related to tools generating code. > >>=20 > >> Suppose you have a software package with several hard-coded fully > >> optimized assembly file for different targets. Your build system need > >> to know the current target as well as target ABI to select the correct > >> assembly file to build it. It even desirable if it includes a simple > >> script to help generate assembly code (like the one in OpenSSL), you'd > >> better know the target ABI to prepare proper glue code without > >> breaking ABI. > >=20 > > hjlu posted examples to the x32 site as to handle this. the only > > difference between x86_64 and x32 is the size of the pointers. >=20 > Besides the pointer size, there are other differences like indirect > branch which need different code sequence on x32 and x64. Indirect > branch would be used in assembly code (yeah, concrete example would > valuable here but indirect branch should be used potentially and > possibly in assembly code.) If the assembly code use indirect branch, > it needs to know the target ABI and generate/use difference code path. in terms of asm code, it's still possible to use ifdef's to handle cases wh= ere=20 you truly need different code paths. in terms of a tool that generates code itself (like gcc), i'm not sure a=20 different tuple would make it any easier. gcc itself simply adds an abi=20 configure flag to control what it supports since the backend shares a lot m= ore=20 code than is unique to each abi. we have precedence here where multiple abi's work with a single tuple, and = it=20 hasn't been a significant hindrance for them. adding a new tuple is also n= ot=20 something to be done lightly ... a lot of code out there parses tuples, and= =20 they would need updating. not that i'm the one to convince here, it's just that you need real data to= =20 back up proposals that shows pros/cons and why your suggestion ultimately h= as=20 more pros than cons ;). -mike --nextPart2503549.NPydE5rOPy Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. Content-length: 836 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAABAgAGBQJOild4AAoJEEFjO5/oN/WBp+YQALa6omZtVlOhQaWZZTKB3I4A 7tsfjTNBgK7u4rtinlyZnHPF5epJC0/x5krLD7OGTJCEn9OiZVLYLmv1riFXxgQN 7/79WZJs3fu81NhX01m+qCpkrYAaSA2yCJxJZKG/QnIWq6DCovWWHZK9MIkQKyyq PsPlKD9vViCNwTdtX6aKPeJIukml49yfSXqQyb/uc1eht95tq1uuHBSYRW3EjwHP qdCbgGBjpYkJ0aBvh+gN2JlBF6cj2WTOyL08fRwn0+JMfcrd1KRKXQKs+7swUs+S XIaNkQU8A50MGRmcV/w1PpkoEttV+Tn/gFe51uuDqKonhMuzYq/8uH2CE4e0U5Zl XrodRKJEoIX2Yuq36RK38APqXtNzxVtioG9HpTvV16kfa/Gmr/UC5T/bBDaCuqDa FhlQu/a9PPS70Mm5lRJtdOGviMGHRI78ud9MO/GEWocdzgl1i1tCNMH/4F+ElvsX feeH6O66r0qiBIhmNsNnI+gjPW7ofDlDBQzxqADBejRfMKCwDCm9jCVgMFJWrJFP hgHv4fdwbu9UNEA5wKKzEeTR4QUxrzAm1eyZenQHVK2IrY6STGUQwQ1B7rLtw0ox TWpaS9uaQ3qQzArn/owOe22jZveKh+JO8/BxdXoBFmKUXf4uDCe08vJDkuslyhTE oPu61wTbBgZh97SaFFib =4JTT -----END PGP SIGNATURE----- --nextPart2503549.NPydE5rOPy--