From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1EAxs7-0006FJ-1o for garchives@archives.gentoo.org; Thu, 01 Sep 2005 22:49:27 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j81MjvlT013048; Thu, 1 Sep 2005 22:45:57 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j81MgvPT011323 for ; Thu, 1 Sep 2005 22:42:57 GMT Received: from minden014.server4you.de ([217.172.177.14] helo=himura.kakuri.org) by smtp.gentoo.org with esmtp (Exim 4.43) id 1EAxoG-0000zq-KR for gentoo-dev@lists.gentoo.org; Thu, 01 Sep 2005 22:45:28 +0000 Received: from localhost (dsl-084-059-062-105.arcor-ip.net [84.59.62.105]) by himura.kakuri.org (Postfix) with ESMTP id 263F879C002 for ; Fri, 2 Sep 2005 00:45:28 +0200 (CEST) From: Christian Parpart Organization: Gentoo Foundation To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] combining x86 and amd64 Date: Fri, 2 Sep 2005 00:45:43 +0200 User-Agent: KMail/1.8.2 References: <20050901171028.GW18440@bmb24.uth.tmc.edu> In-Reply-To: <20050901171028.GW18440@bmb24.uth.tmc.edu> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5381748.TLONnAEzPr"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200509020045.45507.trapni@gentoo.org> X-Archives-Salt: 997ec275-1104-4bfe-9479-ce96ce7b3393 X-Archives-Hash: 6565e40dbb1d0b34f2bdf41ae9f6e6fb --nextPart5381748.TLONnAEzPr Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 01 September 2005 19:10, Grant Goodyear wrote: > The recent discussion about having a "real" x86 arch team and combining > the x86 and amd64 keywords was both interesting and provocative. =20 aha? Not in the list, is it? > Of course, this is the sort of thing that the GLEP system was meant for. > Now that we have a new council that (I hope) will be active in approving > or rejecting GLEPs, perhaps someone should be writing a GLEP about > combining x86 and amd64? This just leads me to assume you're not really a coder (wrt native programm= ing=20 languages like C/C++), are you? I mean, x86 (32bit) and amd64 (64bit) ARE NOT THE SAME ARCH. This is simply demonstrated by all those ugly pointer-to-integer conversion= s=20 that often happen when you write on your legacy x86 architecture. However, when you try to compile it on an amd64 e.g., you just can't as gcc= =20 WILL bail out. Having now a x86amd64-alike keyword instead of x86 and amd64 will just make= =20 lots of user's emerge experiences pain ass. Of course, OTOH, while our bugs db gets flooded with reports, this *could* = be=20 a startup for us to know *what* packages needs fixing. But that way, we wou= ld=20 be jast far off enterprise. Here's an example that works on x86 but *not* an amd64: // g++ -o test32vs64bit test32vs64bit.cpp #include int main() { void *p =3D NULL; unsigned u =3D (unsigned)p; // ok on x86; error on amd64 p =3D (void *)u; // ok on x86; error on amd64 return 0; } Of course, you might think WTF do some guy need this, but hey, programmers = are=20 really creative, and use what the compiler accepts - I myself ran into this= =20 while porting my apps/libs to amd64. And think of it, not everybody has the= =20 money to grab one. Congrats, Christian Parpart. --nextPart5381748.TLONnAEzPr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQBDF4SZPpa2GmDVhK0RAsnYAJwNAZeLEAsD3ppqb4nzwcIiRXQG7wCfcz8U yVtSOhpxnm7lyr0CZuuC1lU= =a1nc -----END PGP SIGNATURE----- --nextPart5381748.TLONnAEzPr-- -- gentoo-dev@gentoo.org mailing list